Fault testing in a telecommunications switching platform

ABSTRACT

In a switching platform of a telecommunications system, fault testing is automatically performed during operation of the switching platform to identify components to be tested, perform testing and if a fail condition occures, perform localization to isolate a source of the fail condition. In another mode of testing, an off-line component is identified and the test procedure automatically performs testing and if a fail condition occurs, a localization procedure is automatically initiated to identify a source of the fail condition. A configuration database containing status information on components of the switching platform can be periodically searched by the fault test procedure to identify components to be tested. The configuration database can also be searched to identify replacement components in response to an alarm identifying a faulty component generated by the fault test procedure.

CLAIM OF PRIORITY

The instant patent application claims priority from the United Statesprovisional patent application designated with serial No. 60/060,107,entitled Cellular Communication System, filed on Sep. 26, 1997.

RELATED PATENT APPLICATIONS

The instant patent application is related to the following patentapplications: (a) U. S. patent application No. 09/026,229, AttorneyDocket No. 24194000.186, entitled SYSTEM AND METHOD FOR DYNAMICALLYMAPPING COMPONENTS WITHIN A TELECOMMUNICATIONS SWITCHING PLATFORM, filedon Feb. 19, 1998 (b) U.S. patent application No. 09/025,740, AttorneyDocket No. 24194000.191, entitled SWITCHING MODULE FOR ATELECOMMUNICATIONS SWITCHING PLATFORM, filed on Feb. 19, 1998; (c) U.S.patent application No. 09/026,485, Attorney Docket No. 24194000.192,entitled SPAN INTERFACE MODULE FOR A TELECOMMUNICATIONS SWITCHINGPLATFORM, filed on Feb. 19, 1998. (c) U.S. patent application No.09/026,488, Attorney Docket No. 24194000.193, entitled SIGNAL-PROCESSINGMODULE FOR A TELECOMMUNICATIONS SWITCHING PLATFORM, filed on Feb. 19,1998; (e) U.S. patent application No. 09/026,321, Attorney Docket No.24194000.194, entitled TELEPHONY-SUPPORT MODULE FOR A TELECOMMUNICATIONSSWITCHING PLATFORM, filed on Feb. 19, 1998; and (f) U.S. patentapplication No. 09/026,486, Attorney Docket. No. 24194000.196, entitiledSYSTEM AND METHOD FOR FORMING CIRCUIT CONNECTIONS WITHIN ATELECOMMUNICATIONS SWITCHING PLATFORM, filed on Feb. 19, 1998.

FIELD OF THE INVENTION

The present invention relates to telecommunications systems and moreparticularly to fault testing of components in a telecommunicationsswitching platform.

BACKGROUND OF THE INVENTION

Telecommunications switching platforms operate to connect incomingcommunication channels to selected outgoing communication channels. Thisswitching is generally done in response to phone numbers dialed by theusers or subscribers of the company operating the telecommunicationssystem, or by others who are calling these subscribers. For example, thecaller enters a phone number and signaling is sent along with or overthe communication channel and the telecommunication system attempts toestablish an end-to-end communications link to the destination numberthat the caller has dialed.

An end-to-end communications channel is established through a switchwithin the telecommunications switching platform. This switch istypically a non-blocking matrix switch, which is operable to connect theincoming channel to one of many outgoing channels. The switch operatesunder control of a processor within the telecommunications switchingplatform. The processor supplies information that the switch uses toconnect one information channel to another through the switch.Typically, the switch receives a number of time-multiplexed inputsignals and provides a number of time-multiplexed output signals. Thereare also typically a number of resources within the switching platform.These resources may be connected to each other or to an informationchannel through the switch. For example, if the caller seeks to initiatea call to a busy number, the caller must receive a busy signal; thisbusy signal is provided by a resource within the telecommunicationsswitching platform, and the familiar busy tone is passed through theswitch and received by the caller.

In conventional telecommunications systems, testing of components isperformed with each component to be tested taken off-line and a test ismanually performed on the component. Such an approach to testing istime-consuming and limits the ability of the telecommunications systemcomponents to be identified as faulty prior to failure of a component ata critical time, e.g., during call processing.

SUMMARY OF THE INVENTION

According to an embodiment of the present invention, components in aswitching platform are automatically tested while the switching platformis in an operational test. A test tone is applied through a loopconnection for the component to be tested and if no tone or the wrongtone is detected, then a localization procedure is initiated to isolatethe fault to a replaceable component. The automatic testing includes abuilt in test mode (BIT) which cycles continuously during operation ofthe switching platform and tests components of the switching platformthat are either idle (e.g., spare DSPs) or that have available timeslotsthat are not used for call processing (e.g., resource processor boards).The automatic testing according to an embodiment of the presentinvention also includes a fault isolation test mode that is manuallyinitiated but then runs automatically on a component that has been takenoff-line (e.g., a span) and if necessary performs fault isolation via alocalization procedure down to a replaceable component.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an embodiment of the claimedtelecommunications switching platform;

FIG. 2 is a block diagram of lower-level functional elements within thetelecommunications switching platform of FIG. 1;

FIG. 3 is a timing diagram illustrating the multiplexing oftelecommunications channels upon the high-speed buses of FIG. 2;

FIG. 4 is a system-level block diagram illustrating how connections maybe formed through the telecommunications switching platform of FIG. 1;

FIG. 5 is timing diagram for several high-speed buses, illustrating theswitching task performed by the switching module of thetelecommunications switching platform.

FIG. 6 is a task flow diagram illustrating the interfaces to aconfiguration task;

FIG. 7 is a flow diagram of the steps taken by the upon startup of thetelecommunications switching platform;

FIG. 8 is a block diagram of the switching module of FIGS. 1-2;

FIG. 9 is a block diagram of the interface module of FIGS. 1-2;

FIG. 10 is a block diagram of the telephony-support module of FIGS. 1-2;

FIG. 11 is a block diagram of the signal-processing module of FIGS. 1-2;

FIGS. 12A-12B is a block diagram illustrating a configuration table usedto store Logical Component Identifiers (LCIs) and other informationconcerning system resources and information channels;

FIGS. 13A-13D illustrate an exemplary flow diagram of the steps taken intranslating and interpreting logical identifiers according to anembodiment of the present invention;

FIG. 14 illustrates timeslot assignments on an exemplary span accordingto an embodiment of the present invention;

FIG. 15 illustrates an exemplary connection path for fault testingaccording to an exemplary embodiment of the present invention;

FIGS. 16A-16B illustrate an exemplary flowchart for fault testingaccording to an embodiment of the present invention;

FIG. 17 illustrates another exemplary connection path for fault testingaccording to an embodiment of the present invention;

FIG. 18 illustrates an exemplary flowchart for fault testing accordingto another embodiment of the present invention;

FIG. 19 illustrates an exemplary connection path for fault testingaccording to another embodiment of the present invention;

FIGS. 20A-20C illustrates an exemplary flowchart for fault testingaccording to another embodiment of the present invention;

FIG. 21 illustrates an exemplary connection path for fault testingaccording to another embodiment of the present invention; and

FIG. 22 illustrates an exemplary flowchart for fault testing accordingto another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a block diagram of an embodiment of the present invention.This block shows the overall telecommunications switching platform 10.This switching platform 10 includes redundant call processors 12 andNetwork Management System ("NMS") servers 14 as well as switchingmodules 16 and resource processors 18, 20, 22 that carry out a number ofthe lower-level tasks to be accomplished by the switching platform 10.Resource processors include, for example, a telephony support module 18,an interface module 20, and a signal-processing module 22. The resourceprocessors are described below, and are described in further detail inU.S. patent application Nos.: 09/025,740 (Docket No. 24194000.191),entitled "Switching Module for a Telecommunications Switching Platform";09/026,485 (Docket No. 24194000.192), entitled "Span Interface Modulefor a Telecommunications Switching Platform"; 09/026,488 (Docket No.24194000.193), entitled "Signal-Processing Module for aTelecommunications Switching Platform"; and 09/026,321 (Docket No.24194000.194), entitled "Telephony-Support Module for aTelecommunications Switching Platform," all of which were filed on Feb.19, 1998 and are hereby incorporated by reference.

The switching modules 16 and resource processors 18, 20, 22 communicatewith each other through, for example, a control bus 24. Data is passedbetween these same elements over high-speed data buses 25, which arepreferably time-multiplexed serial data buses. The operation of thesehigh-speed data buses 25 will be described in greater deal in FIGS. 2-3and the text accompanying these figures.

Still referring to FIG. 1, the switching modules 16 preferablycommunicate with higher-level functional elements (the call processors12, for example) within the platform 10 through communication hubs 26.In an embodiment of the present invention, logical communication pathsare made between the resource processors 18, 20, 22 and the higher-levelfunctional elements via the switching module 16 through, for example,TCP/IP sockets through the communication hubs 26. The higher-levelfunctional elements are described in greater detail in U.S. patentapplication No. 60/060,107, entitled "Cellular Communication System,"naming Anthony G. Fletcher and Scott D. Hoffpauir as inventors, andwhich was filed on Sep. 26, 1997, which is hereby incorporated byreference herein.

The communication hubs 26 connect the call processors 12 to theswitching modules 16 and the NMS servers 14. Preferably, there are twodistinct LANs 28, 30 within the call processor 12. The first LAN 28connects the redundant call processors 12 to the redundant NMS servers14 and redundant switching modules 16 through redundant communicationhubs 26. The second LAN 30 can connect the redundant NMS servers 14 tolocal NMS clients 32 and/or remote NMS clients 34. Connection to remoteNMS clients 34 is preferably performed through a router 36 and a modem38. Since there is no direct NMS client access to the first LAN 28 onwhich the call processors 12, the switching modules 16, or the resourceprocessors 18, 20, 22 operate, the NMS servers 14 may serve as"firewalls" against hacker intrusion into the switching platform 10.

With further reference to FIG. 1, the interface modules 20 connectexternally to telecommunication spans 40 (see FIG. 2), which are, forexample, industry-standard T1 or E1 spans each carrying a number ofinformation channels as specified by the particular standard. Theseinformation channels may be traffic channels or control channels, aswill be discussed below. Connection to the spans are made through spansignal paths 41 from the interface modules to a span connector panel 42,which is the point at which the telecommunication spans 40 (see FIG. 2)physically connect to the switching platform 10.

Collectively, the switching modules 16, resource processors 18, 20, 22,control buses 24, high-speed buses 25, span signal paths 41, and spanconnector panel 42 are referred to as the Input/Output Sub-System("IOSS") platform 27. In one embodiment of the present invention, theIOSS platform 27 resides on a single shelf within a telecommunicationsequipment rack and performs the lower-level functions within thetelecommunications switching platform 10

Control bus 24 preferably comprises a pair of redundant control buses24, over which the various resource processors 18, 20, 22 communicateusing, for example, a Local COMmunication (LCOM) protocol. Although thehigh-speed data buses 25 are sometimes referred to as PCM buses, wherePCM stands for Pulse Code Modulation, which is a digital voice encodingstandard, the data carried on them may include control information,signaling information, data information, and voice information encodedusing other standards. For example, voice information that has beenencoded by a Global Standard for Mobile Communication (GSM) system areencoded using a certain type of Linear Predictive Coding (LPC).Communication hubs 26 are preferably Ethernet Local Area Network (LAN)communication hubs, although the hubs 26 may be hubs for other localnetworking protocols such as, for example, Token Ring or StarLAN. Thecommunication hubs 26 and protocols may operate using either wired orwireless connection schemes. Although the resource processors 18, 20, 22preferably communicate with higher-level functional elements in thesystem through the switching module 16 via Transmission ControlProtocol/Internet Protocol ("TCP/IP") sockets through the communicationhubs 26, other networking protocols are possible. It is also possible,for example, to have such resource processors 18, 20, 22 directlyconnected to the higher-level elements in the system such that they willbe directly addressed by these high-level elements using data andaddress buses.

"Lower-level" functions, which are described above as being performed bythe IOSS platform 27 might be defined, for instance, as all functionswithin the Open System Interconnection ("OSI") framework as being belowthe Session Layer (Layer 4). Under such a division, the IOSS platform 27would be responsible for communications routing and end-to-end deliveryof information, including error recovery and flow control.

FIG. 2 is a block diagram of lower-level functional elements within atelecommunications switching platform 10. At the center of this blockdiagram are the redundant switching modules 16, which are connected tothe higher-level functional elements in the platform 10 through thecommunication hubs 26. Communications between the higher-levelfunctionality and the resource processors 18, 20, 22 are routed through,for example, the active, or ONLINE, switching module 16 instead of theinactive or OFFLINE one of the redundant switching modules 16.

The switching module 16 performs a number of functions. For example, onefunction of the switching module 16 is switching the telecommunicationinformation channels arriving into the platform 10 through thetelecommunications spans 40. As shown in FIG. 2, telecommunication spans40 are connected to the interface modules 20. Information channels aretransmitted within the spans 40 through, for example, time divisionmultiplexing. The switching module 16 contains switches 43, which areresponsible for making the connections between information channelinputs and information channel outputs according to commands from thehigher-level functionality within the platform such as the callprocessor 12. The software function within the call processor 12 thatcontrols switching of the information channels at the applications layermay be called the Resource Manager. These higher-level functions andsystems are described in greater detail in U.S. patent application No.09/026,486 (Docket No. 24194000.196), which is incorporated by referenceherein.

The switching platform 10 is also operable to, for example, receive fromand transmit to GSM-standard mobile phones. Under the GSM standard,wireless voice channels are transmitted at 16 kbps ("kbps"), using LPCcoding, whereas under many land-based telephony standards voice channelsare transmitted at 64 kbps using PCM coding. Thus, in order to connect amobile caller to a land-based called party, it is necessary to adapt therate of the 16 kbps GSM voice channel to the land-based 64 kbpsstandard. This rate conversion is accomplished by, for example, a signalprocessing module 22.

With continued reference to FIG. 2, a GSM Base Transceiver Station (BTS)44 (see FIG. 4) transmits four GSM voice channels on a 64 kbps DS0information channel. The telecommunications switching platform 10connects the 64 kbps DS0 channel from the BTS 44 to a signal processingmodule 22 so that the signal-processing module 22 can convert this DS0information channel into four discrete 64 kbps PCM-encoded channels.These four 64 kbps information channels are then switched to fourdifferent information channels. The final switching of four channels tofour different channels will accomplish the end-to-end switching or willconnect one or more of the GSM voice channels to one of the telephonysupport functions (such as dial tones or DTMF signaling).

Since voice connections are bidirectional or full-duplex, the connectionprocess described above is carried out in the reverse order to receivesignals from the land-based information channels. Thus, the switchingmodule 16 connects one 64 kbps DS0 channel to the signal processingmodule 22, then connects the four 64 kbps channels outputs from thesignal processing module 22 to four different 64 kbps informationchannels, and these connections are duplicated in the reverse direction,for a total of 10 switch connections.

Still referring to FIG. 2, connection is made between the informationchannels and the resource processors 18, 20, 22 and the switchingmodules 16 through a series of high-speed buses 25. As shown in FIG. 2,there are a total of 12 such buses used in this embodiment. For futurecapacity expansion, spare high-speed buses 25 may be included within thetelecommunications rack and switch 43 may be configured to switchinformation channels on these additional buses. For example, four suchspares can be provided for a total of 16 high-speed buses. Each of thesebuses 25, which are operational at an exemplary data rate of 8.192megabits per second ("Mbps"), gives each bus 25 a capacity for 4 E1spans, each E1 span having a data rate of 2.048 Mbps. Each of thesebuses 25 is logically subdivided into 128 timeslots 46 (see FIG. 3).Each of these 128 timeslots 46 may be, for example, a 64 kbps channel.To share each of these buses between the various resources within thetelecommunications switching platform 10, each resource or incominginformation channel is assigned a certain position or timeslot withinthe buses 25 to which they are attached.

The switching module 16 uses a switch 43 to make connections between atimeslot 46 on one bus 25 to a different timeslot 40 on that same bus 25or another bus 25. In an embodiment of the present invention, theswitching module 16 is capable of connecting any of 2048 inputs to 2048outputs. All of these connections can preferably be maintainedsimultaneously. The resources used within the switching platform 10 maybe dynamically assigned based on system needs. As mentioned, theinterface modules 20 form the entry and exit points fortelecommunications spans 40 that are connected to the switching platform10. Each of these interface modules 20 is capable of handling, forexample, four E1 spans 40. Each E1 span may be comprised of 32 channelsincluding 30 voice channels transmitted at 64 kbps, one 64 kbps framingchannel and one 64 kbps signaling channel. There are a total of sixinterface modules 20 shown in FIG. 2, each of which is preferablycapable of handling four spans 40. The switch 43 is preferably aTime-Space-Time switch, which is a space switch (i.e., a matrix switch)interposed between two time switches.

FIG. 8 provides an exemplary block diagram of the switching module 16.In this embodiment, the switching module 16 provides functions such as,for example, switching (SWTH task 70, see FIG. 6); conferencing; datacommunication; local communications (LCOM task 74, see FIG. 6); remoteLAP-D communications (RLPD task 66, see FIG. 6); and an Ethernetinterface.

FIG. 8 shows the switching module 16 from a hardware perspective. Theswitch 43 in this embodiment is, for example, a 2048 by 2048 memorytimeslot, non-blocking switch implementation. The switch 43 may be, forinstance, a Time-slot Interchange Random Access Memory (TSIRAM). Theswitch 43 operates to receive and transmit over a number of high-speedbuses 25, making timeslot cross connections from one timeslot of onehigh-speed bus 25 to a different timeslot within the same high-speed bus25 or another high-speed bus 25, as was discussed with respect to FIG.3. It is possible to accomplish this function using, for example, fourSIEMENS Memory Time Switch Large (MTSL-16) components, although othercomponents may provide the same function. All timeslot cross connectionspreferably take place within this switch 43. This will provide capacityfor sixteen high-speed buses 25 (e.g., 8.192 Mbps buses) to interconnectmodules on the backplane along internal components of the switchingmodule 16. Each 8.192 Mbps bus 25 provides one hundred and twenty-eight64 kbps timeslots.

Still referring to FIG. 8, the Local Communications Function 74preferably comprises a point-to-multipoint control bus link 24 betweenthe switching module 16 and the resource processors 18, 20, 22. Thisfunction is preferably provided by controller 155, which may, forexample, be a SIEMENS Enhanced Serial Communications Controller (ESCC2),although other components are commercially available to serve this localcommunication function. A second link 24 is provided for redundancy.This bus 24 provides part of the communication path between theapplications processor 12 and modules local to the backplane 16, 18, 20,22. The switching module 16 completes the path to the applicationsprocessor through local communication network 28. The switching moduleuses this same network 28 for its communication path to the applicationprocessor 12. The local communication (LCOM) software task 74 isrepresented on FIG. 6, and is executed on the switching module 16.

The network 28 is preferably an Ethernet LAN, connected through a10BaseT connector on the front of the switching module 16 which isimplemented, for example, using a MOTOROLA Enhanced Ethernet Transceiver(EET) and an Ethernet controller that is integrated into the switchingmodule controller 156. The controller 156 additionally providessupervisory control of all the tasks that execute on the switchingmodule 16. Additionally provided, either integrated within thecontroller 156 or as components connected thereto (as shown in FIG. 8),are a memory 158 and a nonvolatile memory 160. The memory 158 preferablystores run-time code and data, and is preferably a Dynamic Random AccessMemory (DRAM) having a capacity of at least 4 Megabytes. The nonvolatilememory 160 preferably stores a non-volatile backup copy of the run-timememory and is preferably a FLASH memory having at least 2 Megabytesstorage. The nonvolatile memory 160 may contain hardware write-protectedblocks of code for boot up. The runtime code can be downloaded andupgraded remotely, whereas preferably the boot code can be upgraded onlyafter on-site removal of the hardware boot₋₋ block₋₋ protection feature.This protection is implemented in this way to protect the reliability ofoperation of the switching 16 module in the event of power failureduring runtime code updates. A temperature monitor 162 may be providedto alarm upon ambient temperature thresholds being exceeded.

With further reference to FIG. 8, the switching module 16 containspreviously-described external connections, which are the redundantcontrol buses 24, the high-speed buses 25, and the network connection17. The switching module 16 also contains an internal address and databus 162, through which the switching module controller 156 can accessthe memories 158, 160 that are internal to the switching module 16. Theswitching module 16 also contains two internal high-speed buses 164,which may, for instance, be used to implement conferencing and LAPDfunctionality through communications with the conferencing unit 150 andthe bus multiplexer 154. The bus multiplexer 154 may in turn beconnected to the network interface controllers 152 through high-speedbuses 166. These high-speed buses 166 arc preferably high-speed serialLAP-D buses, although these buses may also be implemented with a lowerdata rate than is used in the other high speed data bases 25, 164.

A block diagram of exemplary interface module 20 is provided in FIG. 9.The interface module 20 is the point at which the telecommunicationsspans 40 enter the switching platform 10. These connections are shownwhere the four spans 40 enter the interface module 20 and are connectedto four line interface circuits 180. Depending on the ability tointegrate the functions of the line interface circuit 180, thesefunctions could be implemented in a single integrated component or in agreater number of components. Also, although interface module 20 isshown having four span connections, more or less spans 40 could behandled by a single module 20, depending on the state of the technologyused and the complexity of the functions provided in a particularmodule.

With further reference to FIG. 9, a span interface controller 182provides control of the interface module 20. The span interfacecontroller 182 communicates with other components within the interfacemodule 20 through span interface address and data bus 184. The interfacemodule 20 communicates with other components in the IOSS platform 27,particularly with the switching module 16, through the redundant controlbuses 24. The controller 186 is provided to implement the communicationsprotocol by which this communication is carried out. Associated with thecontroller 186 is a nonvolatile memory 188 in which this interfacemodule 20 can maintain its operating code in a nonvolatile fashion.Preferably, this nonvolatile memory 188 is a FLASH memory, wherebyalthough the code is stored a nonvolatile fashion, it can still bechanged with minimal effort. Another memory 189, a DRAM for example, isalso provided for storage of the controller's 182 real-time executablecode and data. A bus multiplexer 190 is provided so that in thisembodiment the four telecommunications spans 40 can be multiplexed intoa single high-speed bus 25 and transmitted to the switching module 16.

With reference now to FIG. 10, a block diagram of the telephony supportmodule 18 is shown. Depending upon system needs, there could be a singletelephony support module 18, or there could be provided a redundantsupport module 18. If a redundant setup were used, the telephony supportmodules 18 would be placed on a single high-speed bus 25 as shown inFIG. 2. Like the interface module 20, the telephony-support module 18comprises a controller 220 for managing the functions provided by thetelephony-support module 18. Also like interface module 20, there isprovided a memory 221 for real-time executable code storage and anonvolatile memory 222 for storage of, for example, the telephonysupport module's boot code or other nonvolatile code. Another purposeserved by the nonvolatile memory 222 within the telephony-support module18 could be for storage of voice messages when voice messaging is afunction supported by the telephony switching platform 10.

Again, like the interface module 20, the telephony support module 18includes a controller 224 that is operable to communicate with the otherresource processors 18, 20, 22, and particularly with the switchingmodule 16 through the redundant control buses 24.

Functions that may be provided by the switching platform 10 includeconferencing, voice messaging, and telephony support functions such asbusy signals, ring signals, trunk busy signals and other functions. Forexample, when a telephone subscriber wishes to place a call, the phonenumber is entered by pressing numbers on the keypad of his phone. Thephone generates DTMF tones that identify each number that is pressed.These tones are passed over an information channel associated with thecalling subscriber. The switching platform 10 processes these DTMF tonesby switching them to one of the resource processors, e.g., the telephonysupport module 18, which decodes the DTMF tones. Once these tones havebeen decoded, the call processor 12 seeks to make a connection inaccordance with the entered phone number. The call processor 12determines which information channel should be connected through to thesubscriber. As the switching platform 10 seeks to make a connection tothe number sought by the subscriber, tones are provided by the telephonysupport module 18 to the subscriber's assigned information channel.These tones would include busy signals and ring signals. Throughout theestablishment of a connection, the switching module 16 is continuallymaking and breaking new connections between the subscriber's assignedinformation channel and various resources within the switching platform10.

With further reference to FIG. 10, the function of generating andinterpreting tones that are carried over the information channels iscalled upon when the switching platform 10 is attempting to establishconnections between a subscriber and the party that the subscriber hasdialed. The telephony support module 18 interprets the DTMF tonesentered by the subscriber, and provides either a busy signal, a ringsignal, or some other signal, as the switching platform 10 attempts tomake a connection to the called party. The DSPs 226 are responsible forthis tone interpretation and generation. A bus multiplexer 228 isprovided to make the appropriate connections between informationchannels that have been routed to the telephony support module 18 and tothe appropriate resources within the telephony support module 18.Specifically, under the direction of a controller 220, the busmultiplexer places incoming tones signals on the appropriate timeslot tobe interpreted by one of the DSPs 226, and will read signals from theDSPs 226 and place them on that high-speed bus 25 in the appropriatetimeslot. Also, under direction of the controller 220, voice messageswill be played back from the nonvolatile memory 222 or stored therein.Again, the bus multiplexer 228, under the controller's 220 direction,will extract the incoming voice channels from the appropriate timeslotsof the high-speed bus 25 and direct them to the appropriate addresswithin the nonvolatile memory 222. In the reverse direction, the busmultiplexer 228 will read the stored messages from the nonvolatilememory 222 and place these messages in the appropriate timeslot on thehigh-speed bus 25.

With reference now to FIG. 11, a block diagram of an embodiment of thesignal processing module 22 is shown. The signal processing module 22 isdesigned for rate-adapting the 16 Kbps GSM-encoded information channels49 to and from the 64 Kbps PCM-encoded information channels 48. Thisfunction is carried out, for example, by digital signal processors("DSPs") 240. To allow flexible provisioning in this embodiment, theDSPs 240 are housed on daughter-boards 242. Up to four daughter-boardsmay be installed on the main module, although fewer daughter boards canbe used if a full complement of daughter boards 242 is not required. Inthis embodiment, the daughter-boards 242 are physically large enough tohold two DSPs 240 each. Assuming, for example, that each DSP can handlefour GSM-encoded voice channels 49, the signal processing module 22 thusprovides up to 32 GSM ports in eight-port increments. The temperaturemonitor 244, the nonvolatile memory 246, the memory 248, the controller250, and controller 252 perform essentially the same functions as do theanalogous components in the other resource processors 18, 20.

The bus multiplexer 254 in the signal processing module 22 isresponsible for connecting, under control of the controller 252,information channels from the PCM high-speed bus 25 to the DSP 240signal processing resources. In addition to performing a rateadaptation, the DSPs 240 can be called upon to perform echo cancelingwhen that function is required, particularly when the switching platform10 is handling GSM-encoded voice channels 49 for example as described inU.S. patent application No. 08/678,254, which is hereby incorporated byreference.. To maximize timeslot flexibility, in an embodiment of thepresent invention, two 32-timeslot highways are available to eachdaughter-board 240. Thus, a fully populated signal-processing module 22would occupy slightly less than one third of a 128 channel, 8.192 Mbpshigh-speed data bus 25. Accordingly, as shown in FIG. 2, each signalprocessing module 22 can share its high-speed data bus 25 with two othersignal-processing modules 22.

FIG. 3 shows how telecommunications channels may be multiplexed onto asingle high-speed bus 25. In this embodiment, 128 traffic and/orinformation channels are multiplexed together to form a single framethat repeats every 125s. Each of the timeslots 46, which are numbered 1through 128 in FIG. 3 and begin repeating again after 128 timeslots,preferably comprises a group of eight contiguous bits occurring every125s. These repeating groups of bits are designated in the exemplarytimeslot 1 (as shown by the break-out figure for that timeslot) as B0through B7.

FIG. 4 illustrates how connections may be formed through atelecommunications switching platform 10. In this embodiment, four GSMmobile phones are shown in wireless communication with a BTS 44. By thetime the GSM-encoded voice signals are transmitted from the BTS 44 tothe switch platform 10, they form a 64 kbps DS0 information channel 49,which would preferably be transmitted within a telecommunications span40 as discussed above. The span 40 is then received by the interfacemodule 20 and is passed from there to the switching module 16. Becausethere is no reason to change the assignment of this GSM-encodedinformation channel 49 into the switching module 16, and because theGSM-encoded information channels 49 will preferably always have to berate-adapted by the signal processing module 22 (in addition to theother signal processing functions the signal processing module 22 mayprovide, which will be later described), it is advantageous tosemipermanently connect and assign the information channel to thesignal-processing module 22. This semi-permanent connection is referredto as an "nailed-up" connection 47. In conventional switching platforms,the addressing information required to maintain this connection throughthe switch 43 is stored in a table within the switching module 16. Theaddressing information would be maintained there until the system isreconfigured or until an error occurred such as a component failure or aboard is removed--which would require the connections to bereconfigured. According to an embodiment of the present invention,however, the addressing information can be dynamically changed toreallocate the connections of selected companies.

Still referring to FIG. 4, within the signal processing module 22, a DS0channel comprising four 16 kbps GSM voice channels is expanded into fourPCM-encoded information channels 48. This expansion is shown within theTranscoder Rate Adaptation Unit (TRAU) functional block of thesignal-processing module 22. These four PCM-encoded voice channels arethen passed again back through the switching module 16. Since thesevarious voice channels are switched in real time so that the GSMtelephone users can make and receive phone calls to differentindividuals, the switching module 16 makes real-time switchingassignments or connections 19 for these PCM-encoded voice channels 48.Thus, the switching module 16 dynamically updates the connectioninformation describing how the circuits will be switched through theswitch 43. In this example, the four PCM-encoded voice channels 48 areall passed through the same or a different interface module 20 and arethen transmitted to the Public Switched Telephone Network (PSTN).

A GSM caller may also call another GSM mobile telephone. In thatcircumstance, one of the PCM-encoded voice channels 48 would bere-routed through the switch 43 to another channel of asignal-processing module 22 to be rate-adapted back to a 16 kbpsGSM-encoded information channel 49 and then passed again through theswitching module 16 and through the original or another interface module20 to the same or another BTS 44.

FIG. 5 is a diagram showing the switching task that is accomplished bythe switch 43 within the switching module 16. On the left-hand side ofthe figure, three exemplary bus inputs and outputs (high-speed buses 25)are shown. In the embodiments described above, there are twelve suchhigh-speed buses 25 that pass through the switch 43. The switch iscapable of receiving all of these buses and switching a timeslot fromany position on any input bus 25 to any position on any output bus 25.For example, in this figure the data from timeslot 1 of input bus 9(B1₋₋ 1) is placed in timeslot 2 of output bus 1, as indicated by thearrow drawn between these positions. Similarly, the data from timeslot 2of bus 1 (B1₋₋ 2) is placed in timeslot 0 of output bus 2 (B2₋₋ 0), andso on. For illustration purposes, a number of other channel connectionsare illustrated in this figure. In the preferred embodiment, the switch43 is capable of connecting in this manner any of 128 timeslots on anyof the twelve input buses 25 to any of 128 timeslots on any of twelveoutput buses 25.

FIG. 6 is a task flow diagram illustrating the interfaces to aconfiguration task ("CNFG") 50 which executes in the switching module 16and is responsible for all physical-configuration-related aspects withinthe platform (e.g., monitoring the number and type of boards, thebackplane configuration, which connections have been "nailed-up," etc.).To maintain the platform database 52, which preferably includes aconfiguration table, messages containing configuration information arerouted through CNFG 50. Upon receiving a message, CNFG 50 updates thedatabase 52 as needed. If the message was destined for the switchingmodule 16, CNFG 50 provides a response if needed. If the message wasdestined for one of the resource processors 18, 20, 22, CNFG 50 forwardsthe message to the appropriate resource processor 18, 20, 22.

According to an embodiment of the present invention, logical componentidentifiers (LCIs) are used as an addressing scheme to, for example,facilitate connections being made by the switching module 16. Accordingto an embodiment of the present invention, an LCI is, for example, a 32bit number that identifies the shelf, slot and board type by the upper16 bits, the lower 16 bits of the LCI being context dependent as afunction of the board type. LCIs can be made by any component needing togenerate an LCI using, for example, a macro or function call that cantake the underlying data, such as the shelf, slot, board type, etc. andput the data into the LCI 32 bit format. For example, LCIs can begenerated by the call processor 12 for each of the spans 40 to identifyto the switching module 16 the traffic channels and LAP₋₋ D channelsthat are to be added, as well as to make and break connections.Similarly, the switching module 16 can generate LCIs to establish nailedup connections, the various LCIs generated representing, for example,the DSPs allocated to each nailed up connection as well as the physicalor logical circuits allocated to a traffic channel. In addition, theLCIs generated according to an embodiment of the present invention canbe used as indices to the CNFG database 52 illustrated in detail inFIGS. 12A and 12B and discussed below.

The CNFG task 50 provides an interface to translate LCIs into high-speedbus 25 and timeslot 46 data for a SWTH task 70. The SWTH taskestablishes connections in the switch 43. These logical identifiersserve as indices to configuration database 52 that provides physicalconnection information to the CNFG task 50. CNFG task 50 passes theconnection information to the switch 43 to make the appropriateconnections between information channels on the high-speed buses 25. TheCNFG task 50 will determine certain LCIs at system start-up.

An example of the building of a LCI is during system startup, at whichtime the switching module 16 receives description data from eachinstalled resource processor 18, 20, 22, for example in the form of aregistration message. When the registration information is received bythe switching module 16, the CNFG task 50 utilizes the registrationinformation (e.g., shelf, slot, board type) and builds a board LCI foreach resource processor 18, 20, 22. The call processor 12 can also buildLCIs. For example, the call processor 12 includes initial information onthe components of the system (e.g., based on information manuallyprovided by an operator during installation of the system), such as spanconfiguration and the configuration of individual timeslots. Thus, theinformation known by the call processor 12 as well as registrationinformation provided from the switching module 16 to the call processor12 at startup of the switching module 16 can be used by the callprocessor 12 to build LCIs for spans 40 on each interface module 20. TheCNFG task 50 in the switching module 16 or the call processor 12 canuse, for example, the exemplary macros set forth below to build andmanipulate each LCI which can be implemented in the C programminglanguage. For example, the MAKE macros put the data into the properfields of the LCI while the GET macros allow retrieval of the particularfields of interest in the LCI.

    ______________________________________                                        //   LCI Construction Macros                                                  #define     MAKE.sub.-- TRUNK.sub.-- LCI(SHELF,SLOT,BD.sub.-- TYPE,                   SPAN.sub.-- TYPE,SPAN,LCKT)                                           #define     MAKE.sub.-- SPAN.sub.-- LCI(SHELF,SLOT,BD.sub.-- TYPE,                    SPAN.sub.-- TYPE,SPAN)                                                #define     MAKE.sub.-- BOARD.sub.-- LCI(SHELF,SLOT,BD.sub.-- TYPE)           #define     MAKE.sub.-- CC.sub.-- LCI(SHELF,LCKT)                             #define     MAKE.sub.-- DSP.sub.-- LCI(SHELF,SLOT,DSP)                        #define     MAKE.sub.-- SPM.sub.-- TEST.sub.-- LCI(SHELF,SLOT,CHAN)           #define     MAKE.sub.-- SPM.sub.-- CHAN.sub.-- LCI(SHELF,SLOT,DSP,CH)         #define     MAKE.sub.-- PSM.sub.-- CHAN.sub.-- LCI(SHELF,CH)                  #define     MAKE.sub.-- CONFERENCE.sub.-- LCI                                         (SHELF,CONFID,MUSACPORT)                                              //   LCI extraction macro's                                                   #define GET.sub.-- SHELF.sub.-- FROM.sub.-- LCI(LCI)                          #define GET.sub.-- SLOT.sub.-- FROM.sub.-- LCI(LCI)                           #define GET.sub.-- SPAN.sub.-- TYPE.sub.-- FROM.sub.-- LCI(LCI)               #define GET.sub.-- SPAN.sub.-- FROM.sub.-- LCI(LCI)                           #define GET.sub.-- CKT.sub.-- FROM.sub.-- LCI(LCI)                            #define GET.sub.-- BD.sub.-- TYPE.sub.-- FROM.sub.-- LCI(LCI)                 #define GET.sub.-- DSP.sub.-- FROM.sub.-- LCI(LCI)                            #define GET.sub.-- PSM.sub.-- CHAN.sub.-- FROM.sub.-- LCI(LCI)                #define GET.sub.-- SPM.sub.-- TEST.sub.-- CHAN.sub.-- FROM.sub.--             LCI(LCI)                                                                      #define GET.sub.-- CONF.sub.-- ID.sub.-- FROM.sub.-- LCI(LCI)                 #define GET.sub.-- PORT.sub.-- FROM.sub.-- CONF.sub.-- LCI(LCI)               ______________________________________                                    

According to an embodiment of the present invention, LCIs are 32 bitsalthough all of the bits may not be used for each LCI. For example, whenaddressing IOSS Platform boards 27, the LCI is constructed using theshelf, slot, and interface fields. Any remaining fields will be set toNONE. All boards within the IOSS Platform 27 (e.g., resource processors18, 20, 22) are addressable in this manner. The below table demonstratesBoard LCI 0×0054FFFF, residing at slot 5 on shelf 0 and is a board type4 , which an arbitrarily selected designation for an interface module 20according to an embodiment of the present invention.

    ______________________________________                                        Shelf Slot    Board Type Span Type                                                                            Span  Logical circuit                         ______________________________________                                        4 bits                                                                              8 bits  4 bits     4 bits 4 bits                                                                              8 bits                                  0×0                                                                           0×05                                                                            0×4  0×F                                                                            0×F                                                                           0×FF                              ______________________________________                                    

Preferably, the upper or most significant 16 bits of the above exemplary32-bit logical identifiers or LCIs consistently provide the same typesof information, i.e., shelf, slot, and board type. The lower 16 bits arepreferably context-sensitive, depending upon the type of resource orcommunication channel that is being identified. 0× indicates ahexadecimal number. To make this LCI, the shelf slot and board type data(e.g., 0, 05, 4) would be provided to the the MAKE₋₋ BOARD₋₋ LCI macrowhich would generate the LCI. Similarly, to extract data from this LCI(e.g., when the LCI is received at its destination), the appropriate GETmacro would be used to extract the necessary information based on themessage type (e.g., adding a traffic channel requires extracting thespan field).

To create a LCI for a span 40 on an interface module 20, a trunk LCIwould be used to address individual circuits (e.g., DS0s) on aninterface module 20. When the specified span being addressed isconfigured as a land span (e.g., a PSTN span), the physical circuits areused to construct the LCI, as each timeslot (DS0) on the span carries aPSTN traffic channel. However, if the specified span is configured as anair span (e.g., a GSM span), then logical circuits are used to do themapping to the air traffic channel, as each physical timeslot (e.g., a64 kbps DS0) carries four air traffic channels (e.g., 4 16kbpsGSMtraffic channels). Thus, a single span carries 32 physical timeslotsaddressed by a physical circuit, each physical timeslot supporting fourair traffic channels resulting in 128 air traffic channels that can beaddressed via a logical circuit. When nailing up a connection for an airspan, however, logical circuits cannot be used because a single DSPsupports one physical circuit and four logical circuits. Thus, thenailed up connection for four air channels uses the same DSP and thusthe nailed up connection for the four air traffic channels must be usethe physical timeslot of the DSP. Thus, according to an embodiment ofthe present invention, an air span LCI can contain a force physical bitthat when set causes the appropriate physical circuit to be used for thenailed up connection, the force physical bit then being not set so thatthe logical circuits are used for call processing. The force physicalbit can be, for example, the most significant bit (MSB) of the logicalcircuit field. Therefore, when specifying a trunk connection to theplatform 27, LCIs for trunks may, for example, be constructed asfollows:

    ______________________________________                                        Shelf Slot    Board Type Span Type                                                                            Span  Logical circuit                         ______________________________________                                        4 bits                                                                              8 bits  4 bits     4 bits 4 bits                                                                              8 bits                                  0×0                                                                           0×05                                                                            0×4  0×0                                                                            0×0                                                                           0×07                              ______________________________________                                    

The above example is for a land circuit (also known as a PSTN trunk)having an LCI of 0×00540007. The first five fields are preferably fixedfor all the LCIs on a particular span. The last field, "logicalcircuit," maps differently based on the interface and circuit type. Inthis example, the interface is an E1 standard land span indicated by 0×0in the span type field and 7 in the logical circuit indicating timeslot7 of the physical circuit (e.g., one of the 32 physical circuits on eachspan). An airspan would have a different span type and the logicalcircuit field would contain a number between 0 and 127 referring to oneof the four logical circuits associated with each of the 32 physicalcircuits. For any DS0 allocated for a LAPD channel, a group of fourlogical circuit numbers will be allocated but only the first will beused to access the LAP-D signaling channel.

When addressing spans 40, the LCI is constructed using all of thefields, except for the logical circuit field. The logical circuit fieldis preferably set in this circumstance to 0×FF. Spans 40 are preferablyaddressable via the interface modules 20. Both the Span LCIs and theChannel LCIs (eg., the last field of the LCI) refer to an interfacemodule 20. Accordingly, the range of permissible values for "Slot" wouldbe the same for either a Span LCI or a Channel LCI-specifically, thepermissible range would be those slots where an interface module 20could be placed on the shelf. Further the Board Type would be the samefor either, specifically "4" in this exemplary embodiment referring toan interface module 20. The Span Type and Span for Channel LCIs and SpanLCIs would also have the same range of values, as when identifying aparticular Channel LCI, one must first identify the span 40 on whichthat channel is being carried. The Channel LCI contains the additional,final field that identifies the time slot 46 of the information channelwithin a particular span 40. For landbased spans having 64 kbps PCMinformation channels, there will be 32 timeslots (or Channel LCIs) perSpan LCI. Since GSM-based voice channels are encoded at 16 kbps, whenthe span 40 carries nothing but GSM-encoded voice channels there will be128 timeslots or Channel LCIs per Span LCI (4 channels within each 64kbps timeslot).

DSP LCIs are used when accessing signal processing module 22 ortelephone support module 18 resources. DSP LCIs can be used to identifyindividual DSPs. The LCI below illustrates a DSP LCI.

    ______________________________________                                        Shelf  Slot     Board Type                                                                              Unused  DSP  Channel                                ______________________________________                                        4 bits 8 bits   4 bits    4 bits  4 bits                                                                             8 bits                                 0×0                                                                            0×0x                                                                             0×2 or 0×3                                                                  0×F                                                                             0×0                                                                          0×FF                             ______________________________________                                    

For a DSP LCI on a signal processing module 22, the DSP field rangesfrom 0-8 (e.g., there are 8 DSPs on each module 22) and individual DSPsare addressed 1-8 with 0 indicating a broadcast message to all DSPs. Fora DSP LCI on a telephony support module 18, the DSP field ranges from0-6 (e.g., there are 6 DSPs on a module 18) and individual DSPs areaddressed 1-6 with 0 indicating a broadcast message. While a DSP LCI fora signal processing module identifies an individual DSP, the Channelfield identifies whether the encoded DSP connection 48 or one of thedecoded DSP connections 49. For a telephony support module 18, theChannel field represents, for example, the type of tone generated by theDSP.

According to an exemplary embodiment of the present invention, whenforming connections, the application layer, which is comprised of thecall processor 12, for example via a resource manager within the callprocessor 12, provides the LCI for the two endpoint information channelsthat the call processor 12 wishes to connect. The IOSS platform 27 formsall intermediate connections through the switch 43, including anyconnections that may be required through the signal processing modules22 in a manner that is transparent to the call processor 12 and theresource manager.

This method and system for providing logical identifiers for componentsand communications channels provides a way to identify, preferablythroughout the entire platform, all elements and channels to beconnected and to make connections between those elements. A standardformat is provided that builds up a LCI in a building block manner thatcan also be used as indices to a database of configuration informationto allow dynamic updating of the database and remapping of connectionswithout involving the call processor. In addition, the LCIs according toan embodiment of the present invention can be built as needed by variouscomponents thereby reducing the burden on the call processor to track anentire set of connections and allowing alternate connection paths to beestablished without invoking call processor logic. This providessignificant flexibility over prior-art systems in which incoming lines,outgoing lines, and platform resources are identified in a single listor database that is generally accessed by a single process that isresponsible for managing the formation of these connections.

The CNFG task 50 provides a function to translate LCIs into thehigh-speed bus 25 and timeslot 46 information. This function preferablytranslates one or two LCI values with one operation. In an embodiment ofthe present invention, there are, for example, three parameters to thisfunction: count; lci₋₋ xlate₋₋ ptr; and phys₋₋ xlate₋₋ ptr. The countparameter will specify the number of LCI values to translate. Thepreferred range is 1 or 2. The lci₋₋ xlate₋₋ ptr points to a 32-bitarray, maintained by the function requesting the translation, thatcontains the LCI values to translate. The phys₋₋ xlate₋₋ ptr points toan array of structures that will contain the translated line and slotdata for each of the input LCI values that is also established by thefunction requesting the translation. This function returns a zero value,unless an error is encountered. LCIs that identify individualcommunications paths (timeslots on spans) will be translated to physicalcircuits within the IOSS Platform 27. Additionally, the CNFG task 50(see FIG. 6) maintains the look-up tables needed to translate LCIs (seeFIGS. 12A-12B)

Also, CNFG task 50 provides interfaces to report alarms and softwareerrors. Alarms caused by the switching module 16 are considered localalarms, while alarms generated by resource processors 18, 20, 22 areconsidered remote alarms. In any case, both types of alarms are passedto the CNFG task 50 for processing. Operationally, this task 50maintains and controls physical platform configuration information,hardware fail-overs, and process "hot-removal" and "hot-insertion" ofresource processor or other boards. The CNFG task 50 also manages thestate of the switching module 16 and monitors the status of the resourceprocessors 18, 20, 22 within the switching platform 10. CNFG 50maintains a table of state information for each resource processor 18,20, 22 and for the redundant switching modules 16.

As shown in FIG. 6, the CNFG task 50 interfaces with the resourcemanager software modules running on the call processors 12 and many ofthe other tasks executing within the IOSS platform 27. These interfacesmay be implemented, for example, by the use of message queues. CNFG 50interfaces with each task's command mailbox. The CNFG 50 task acceptscommands through its message queue, Cnfg₋₋ Qid 54. In an embodiment ofthe present invention, the messages arriving in the queue 54 via MSGItask 56 originated in the Resource Manager.

After processing startup initialization functions, this CNFG task 50 isdriven by, for example, an event flag. The event flag indicates that amessage has been placed in CNFG's message queue, Cnfg₋₋ Qid 54.Preferably, all configuration-related messages pass through CNFG 50. TheCNFG task 50 may be commanded by the Resource Manager to issuestate-change commands (e.g., ONLINE, OFFLINE) to boards residing withinthe IOSS platform 27. Also, board additions and removals are preferablydetected and reported to this task. Finally, in addition to maintainingplatform configuration, this task effects redundant fail-overs whennecessary.

All objects required by the CNFG task 50 are preferably available atstartup. The CNFG task 50 starts by initializing itself and resettingall configuration tables. During startup, the task reads a systeminformation and status register on the switching module 16. The resultsof this read are then made available to the other tasks within the IOSSplatform 27. This information is also preferably made available in aglobal data structure. Information that may be included in this globaldata structure include, for example, the following fields:

    ______________________________________                                        write.sub.-- protect:                                                                  Indicates whether the bootstrap portion of the                                IOSS platform                                                                 27 is write protected                                                shelf address:                                                                         Indicates on which shelf of a telecommunications                              rack the IOSS platform resides                                       slot.sub.-- id:                                                                        Indicates in which slot of a telecommunications rack                          shelf a module has been placed                                       hardware info:                                                                         may be used to provide model and revision                                     information for the rack backplane and/or module                     ______________________________________                                                 PCB                                                              

The IOSS software includes, for example, the following tasks:

    ______________________________________                                        BIT 82        Built In Test                                                   CNFG 50       Configuration                                                   LCOM 74       Local Communications                                            RLPD 66       Remote LAP-D                                                    SWTH 70       Switch                                                          TSIG 78       Trunk Signaling/PCM Message support                             WDOG (not shown)                                                                            Watchdog                                                        TONE (not shown)                                                                            Tone control                                                    SYNC 90       Redundancy control                                              HFSP (not shown)                                                                            Handoff and clock slip processing                               TSIG 78       TSI supplied LAPD stack tasks.                                  ______________________________________                                    

The Message Router In 56/Message Router Out 62 (MSGI/MSGO) tasks is onepoint of communication between the IOSS platform 27 and the ResourceManager, and is preferably implemented through a pNA socket interface.MSGI 56 reads from a socket and routes the messages to the properdestination within the IOSS platform 27. Messages may be deliveredlocally to other tasks executing on the switching module 16, over aremote LAP-D link to the BTS 44, or over the LCOM link 24 to variousresource processors 18, 20, 22. MSGI 56 blocks on socket reads if datais not available. MSGO 62 preferably uses one input message queue,blocks on a read from the queue, and delivers the messages to the properdestination.

The Loader (LDER) task 86 performs downloads to nonvolatile memory 160and is the file handler for downloads to the resource processors 18, 20,22. Download messages are received from Resource Manager (RM) via theMSGI task 56. The download messages may indicate boot block loads,executable loads, or loads to Field Programmable Gate Arrays (FPGAs) inthe resource processors 18, 20, 22 or switching module 16. For each ofthe three downloadable entities managed by LDER 56, there is a knownfile name that LDER 56 will use. These files preferably reside on a diskthat is capable of being NFS-mounted and accessed directly by LDER 56.The results of the download will be sent up to the Resource Managerthrough MSGO 62.

The Built-In Test (BIT) task 82 will, under normal operation,periodically execute a list of built-in diagnostic tests. The BIT task82 is described generally below and in detail regarding FIGS. 15-22 . Oneach iteration of a test, BIT 82 attempts to test, for example, either aresource processor 18, 20, 22 or a DSP. Statistics preferably will bemaintained, indicating the number of tests performed or attempted pertimeslot.. A failed BIT, based on specific data associated with eachtest, will cause an alarm to be sent to CNFG task 50 that may result ina request to fail-over to a redundant component.

To maintain the platform configuration information, CNFG task 50 handlesresource processor 18, 20, 22 board insertions and extractions. Theremoval of any resource processor 18, 20, 22 is preferably detected atrun-time by LCOM 74 and reported to CNFG 50. The Resource Managerdetects the removal of a switching module 16 at run-time. CNFG 50reports the board removal (except for switching module 16 removal) tothe Resource Manager and adjusts the database 52 to reflect the newhardware status. Additionally, CNFG 50 generates disconnect commands forSWTH 70 if the board removed was currently in use. If a switching module16 is hot-inserted into the IOSS platform 16, it will automaticallybecome the off-line switching module 16. The SYNC task 90 ensures thatthe newly-inserted switching module 16 is synchronized as quickly aspossible with the existing switching module 16 in case a failover isnecessary. If a telephony-support module 18 is hot-inserted into asystem, it automatically becomes an off-line slave.

Any signal processing modules 22 added to the IOSS platform 27 atrun-time are also detected by LCOM 74 and reported to CNFG 50. CNFG 50reports the board addition to the Resource Manager and adjusts thedatabase 52 to reflect the new hardware status. SWTH 70 does not need tobe told about signal-processing module 22 additions. Adding asignal-processing module 22 will increase the pool of DSPs 240 (see FIG.11) available to the IOSS platform 27.

With continued reference to FIG. 6, any interface modules 20 added tothe IOSS platform 27 at run-time are detected by LCOM 74 and reported toCNFG 50. In this embodiment, CNFG 50 reports the board addition to theResource Manager and then adjusts the database 52 to reflect theaddition. CNFG 50 preferably will not by itself place the new spans 40into service. If spans 40 are connected, TSIG 78 receives a messageindicating that the span 40 is active. The Resource Manager thenrequests that the specified span 40 be brought into service.

The Local Communications (LCOM) task 74 establishes and maintains apoint-to-multipoint connection and connectivity to the resourceprocessors 18, 20, 22 within the IOSS platform. In one embodiment, eachresource processor 18, 20, 22 within the IOSS platform uses its slot idas its identifier. LCOM 74 identifies resource processors 18, 20, 22that are currently active in the IOSS platform 27 and periodically pollsunused slots to determine if a board has entered the system. LCOM 74recognizes and reports when resource processors 18, 20, 22 are no longercommunicating or when one of the links has failed.

Still referring to FIG. 6, the Remote LAP-D (RLPD) task 66 provides allcommunications to the BTS 44. RLPD is accessed via special messages fromResource Manager to establish connections, pass messages to the BTS 44and release connections.

The Switch (SWTH) 70 task services the Resource Manager. SWTH 70receives messages from the Resource Manager, via MSGI 56. Based on thereceived message, SWTH 70 makes the necessary connections through theswitch 43. The results of commanded actions will be sent to the ResourceManager through MSGO 62. Another function of SWTH 70 is to service BIT82 requests to establish connections to perform testing. SWTH 70maintains a table indicating current timeslot connections and status(operational, BIT, unused, etc.).

Preferably, all of the connections in the interface modules 20, signalprocessing modules 22 and telephony support modules 18 will be"nailed-up" connections 47 so that reql time switching occurs primarilyin the switching module 16. BIT 82 will also be able to requesttemporary loop-back connections. The resource processors 18, 20, 22 canbe initialized to their "nailed-up" connections 47, but will alsorespond to run-time commands requesting connections or disconnections.

The Watchdog (WDOG) task (not shown) periodically services a hardwarewatchdog to prevent system resets. This task also polls the systeminformation and status bits to determine a change of bus ownershipstate. If a change is detected, a message will be sent to CNFG 50.Additionally, this task will flash an LED to indicate that the IOSSplatform 27 is running.

FIG. 7 is a flow diagram of the steps taken by the CNFG task uponstartup of the IOSS platform 27. After initialization of the switchingmodule 16, CNFG task 50 builds up empty configuration tables based onits read of the system information and status register (e.g., stored ina hardware register of the switching module 16) and described furtherwith regard to FIGS. 12A and 12B.

As shown in FIG. 7, the configuration table 52 is initially constructedin step 112 as an empty table whose size and fields are determined bywhat the CNFG task 50 has read from the information and status registerof the switching module 16. Once the empty configuration table 52 hasbeen constructed in step 112, at step 114 each switching module 16 sendsa "Ready" message to the Resource Manager. Each switching module 16 atthis time also reports its state, i.e., one of the switching modules 16is ONLINE while the other switching module 16 is OFFLINE. The switchingmodule 16 that is ONLINE then begins at step 116 to receiveconfiguration information from each resource processor 18, 20, 22 thatis in communication with the switching module 16. Also at step 116, theswitching module 16 continues after updating the configuration table 52and provides the Resource Manager with this configuration information sothat the Resource Manager can keep its system configuration databasecurrent. FIGS. 12A and 12B further illustrate the building of database52.

The CNFG task 50 continues at step 118 in which the switching modules 16receive a SET₋₋ CLOCK message from the Resource Manager. Both the ONLINEand the OFFLINE switching module 16 receive the SET₋₋ CLOCK message, soboth of the switching modules 16 can be synchronized with the ResourceManager. For those resource processors 18, 20, 22 that are in the resetstate, executable code is preferably loaded therein. In step 120, theResource Manager issues LOAD messages for each resource processor 18,20, 22 that is in the RESET state. The LDER task 86 (see FIG. 6) withinthe switching module 16 is responsible for processing these downloads tothe resource processors 18, 20, 22.

With further reference to FIG. 7, the call processors 12 along with theswitching modules 16 begin the task of assigning resources to trafficchannels 49, and control and signaling (e.g., LAPD protocol in thisembodiment) channels 48. This occurs at step 122, where the ResourceManager generates and sends ADD₋₋ TCH and ADD₋₋ LAPD messages to theCNFG task 50. At step 122, for each "add" message, the CNFG task 50 willestablish "nailed-up" connections 47 through the necessary interfacemodules 20 and signal-processing modules 22 and will send appropriateconnection commands to the SWTH task 70. Still at step 122, for allADD₋₋ TCH messages, CNFG 50 will attempt to locate and assign (byissuing the nailed-up connection request to the SWTH task 70, see FIG.6) signal-processing module 22 resources. For all ADD₋₋ LAPD messages,CNFG 50 will locate and assign (by issuing a nailed-up connectionrequest to the SWTH task 70, see FIG. 6) LAPD controller resourceswithin the switching module 16. Once these steps have been completed,the CNFG task is at step 124, and the IOSS platform 27 is ready to placecalls.

FIGS. 12A and 12B illustrate an exemplary configuration table 52 used tostore individual board configuration information and information used totranslate Logical Identifiers or LCIs into switch 43 high-speed bus 25and timeslot 46 information. The CNFG task 50 creates and maintains aglobal configuration table 260. The table 260 contains the necessaryplatform configuration data and will be modified by the CNFG task 50,but will be read by one or more tasks within the switching platform 10.The table 260 is preferably statically configured, assuming all slotsused, with recommended board layouts but is by dynamically updated asneeded. The fields, field types, and comments for table 260 are shownbelow. When the switching module 16 starts up, each resource processor18, 20, 22 connected to the switching module 16 checks in as describedpreviously via a registration message. CNFG task 50 then updates thedatabase 52. For example, the fields in table 260 can be updated as eachboard checks in. In particular, field 278 is an array field that isupdated for each board (e.g., there are up to twenty entries of boarddata, one for each board). The contents of field 278 are shown at table300 in FIG. 12A and described below.

    ______________________________________                                        Field Name    Field Type                                                                             Comments                                               ______________________________________                                        Pcm.sub.-- bus.sub.-- state (262)                                                           UINT1    Indicates which of the redundant                                              switching modules is ONLINE                                                   and owning the high-speed                                                     buses 25.                                              Lock.sub.-- ind (264)                                                                       UINT1    Indicates lock state of                                                       switching module 16:                                                          CNFG.sub.-- CMD.sub.-- LOCK or                                                ˜CNFG.sub.-- CMD.sub.-- LOCK                     Shelf (266)   UINT1    Identifies whether the current                                                shelf is shelf 0 or shelf 1                            Slot (268)    UINT1    Identifies the slot in which                                                  the switching module 16 is:                                                   SDM.sub.-- SLOT.sub.-- A or                                                   SDM.sub.-- SLOT.sub.-- B                               Clock.sub.-- source (270)                                                                   UINT4    Identifies the current clock                                                  source, e.g.,                                                                 INTERNAL.sub.-- CLOCK,                                                        CLOCK.sub.-- 1, CLOCK.sub.-- 2,                                               CLOCK.sub.-- 3, or CLOCK.sub.-- 4                      Clock.sub.-- source.sub.-- rate (272)                                                       UINT4    Indicates the current clock                                                   source rate: SPAN.sub.-- TYPE.sub.-- E1                                       or SPAN.sub.-- TYPE.sub.-- T1                          Online.sub.-- psm.sub.-- slot (274)                                                         UINT1    Identifies the slot of                                                        the ONLINE telephony-support                                                  module 18.                                             ______________________________________                                    

    ______________________________________                                        Stats (276)                                                                            CNFG.sub.-- PLATFORM.sub.--                                                                  Is a structure 276                                             STAT.sub.-- TYPE                                                                             containing counts of installed                                                hardware components.                                  Board[] (278)                                                                          CNFG.sub.-- BOARD.sub.--                                                                     Is an array 278 of                                             TYPE           specific board-related data.                                                  This array is preferably sized                                                to be one greater than the                                                    largest number of boards that                                                 may reside in the switching                                                   platform 10. The extra slot                                                   is used for cross-connects                            ______________________________________                                    

As the resource processors 18, 20, 22 check in with the switching module16, the registration information is used by CNFG task 50 to update thestats field 276, which contains, for example, information concerning thenumber and type of boards installed in the switching platform 10, alongwith the total number and allocated number of various system resources.The stats filed 276 contains, for example, the field names and types setforth below.

    ______________________________________                                        Field Name Field Type                                                                             Comments                                                  ______________________________________                                        Inst.sub.-- sdm (282)                                                                    UINT4    The bit position indicates the card-rack                                      slot and the number of bits set indicate                                      the number of installed boards.                           Inst.sub.-- psm (284)                                                                    UINT4    Same as above                                             Inst.sub.-- qsm (286)                                                                    UINT4    Same as above                                             Inst.sub.-- spm (288)                                                                    UTIN4    Same as above                                             Total.sub.-- spans (290)                                                                 UINT2    Total number of span interfaces                                               known to the platform                                     Land.sub.-- spans (292)                                                                  UINT2    Number of spans 40 allocated to land                                          circuits                                                  Air.sub.-- spans (294)                                                                   UINT2    Number of spans 40 allocated to air                                           circuits                                                  Bp.sub.-- type (296)                                                                     UINT1    Current backplane type                                    Cur.sub.-- bp.sub.-- slots (298)                                                         UINT1    Current number of backplane slots                         ______________________________________                                    

The land-spans field 292 and air-spans field 294 define the number ofspans 40 allocated to land and air circuits. For example, there will bea defined number of radios associated with a particular switchingplatform 10 and thus there exists a defined number of air trafficchannels to be assigned by the call processor 12. As the equipmentassociated with the switching platform 10 is known to the applicationprocessor 12, the application processor, at the time of systeminitialization, can determine the allocation of spans 40 between landand air.

The board field 278 of the configuration database 260 is, for example,an array field and contains board-related information and is dimensionedto have an array size of one more than the largest number of boards("n") that may reside in the switching platform 10. Backplane slots arenumbered 1 to n. The resource processors 18, 20, 22 will report theirslot numbers to CNFG 50 when the resource processors check in with theswitching module 16. Array 278 thus contains information concerning eachresource processor 18, 20, 22 currently registered with the switchingmodule 16. The registration information provided to switching module 16in combination with the configuration information known by the callprocessor 12 and provided to the switching module 16 allows the CNFGtask 50 to update tables 260, 280 and 300, including building board LCIsto be stored in field 302 (e.g., the upper 16 bits of the LCI--shelf,slot, board type).

Array 278 will also be used to translate LCI values to switch 43high-speed bus 25 and timeslot 46 information, also described withrespect to FIGS. 13A and 13B. Board types for every slot will start intable 300 as NO₋₋ BOARD in field 304, and are updated as boardsregister. Board states will start as UNKNOWN and are updated as boardsregister. The config₋₋ ptr field 324 is then cast to an appropriateboard type, based on the type field. For example, a signal processingmodule 24 board would cause field 324 to be set to the signal processingboard type and would provide a pointer to, for example, table 346 shownin FIG. 12B. As long as the type field is NO₋₋ BOARD, no attempt is madeto access this pointer. During CNFG's 50 initialization, the config₋₋ptr field 324 of each array element will be set to the address of astatically-allocated structure of the recommended board type for eachslot, based on backplane type. Once set, this field 324 will preferablynot change unless a system reset is performed.

    ______________________________________                                        Field Name                                                                              Field Type                                                                             Comments                                                   ______________________________________                                        LCI (302) UINT4    Board LCI value.                                           Type (304)                                                                              UINT1    Board type: NO.sub.-- BOARD,                                                  BOARD.sub.-- SDM, BOARD.sub.-- SPM,                                           BOARD.sub.-- PSM,                                                             BOARD.sub.-- QPM.sub.-- E1,                                                   BOARD.sub.-- QPM.sub.-- T1                                 State (306)                                                                             UINT1    Board state: UNKNOWN.sub.-- ST,                                               RESET.sub.-- ST,                                                              OFFLINE.sub.-- ST, ONLINE.sub.-- ST,                                          ERROR.sub.-- ST,                                                              IN.sub.-- TEST.sub.-- ST, LOADING.sub.-- ST                Prev.sub.-- state (308)                                                                 UINT1    see state field above                                      Code.sub.-- version[]                                                                   CHAR1    An array of                                                (310)              CODE.sub.-- VERSION.sub.-- LENGTH bytes                                       used to contain the code version for a                                        specific board.                                            Boot.sub.-- version[]                                                                   CHAR1    An array of                                                (312)              CODE.sub.-- VERSION.sub.-- LENGTH bytes                                       used to contain the boot version for a                                        specific board.                                            Fpga.sub.-- version[]                                                                   CHAR1    An array of VERSION.sub.-- LENGTH                          (314)              bytes used to contain the FPGA version                                        of a specific board.                                       Dsp.sub.-- version[]                                                                    CHAR1    An array of                                                (316)              CODE.sub.-- VERSION.sub.-- LENGTH bytes                                       used to contain the FPGA version for a                                        specific signal-processing module 22 or                                       telephony-support module 18.                               Vm.sub.-- time[] (318)                                                                  CHAR1    An array of                                                                   CODE.sub.-- VERSION.sub.-- LENGTH bytes                                       used to contain the voice message version                                     for a specific telephony-support                                              module 18.                                                 Tone.sub.-- version[]                                                                   CHAR1    An array of                                                (320)              CODE.sub.-- VERSION.sub.-- LENGTH bytes                                       used to contain the tone version for a                                        specific telephony-support module 18.                      Rev.sub.-- number                                                                       UINT2    Hardware revision of board.                                (322)                                                                         *config.sub.-- ptr                                                                      VOID     Cast to appropriate type, based on                         (324)              specified type field. No attempt to cast is                                   made if type = NO.sub.-- BOARD.                                               Valid casts:                                                                  SDM.sub.-- BD - CNFG.sub.--                                                   SDM.sub.-- BOARD.sub.-- TYPE                                                  SPM.sub.-- BD - CNFG.sub.--                                                   SPM.sub.-- BOARD.sub.-- TYPE                                                  PSM.sub.-- BD - CNFG.sub.--                                                   PSM.sub.-- BOARD.sub.-- TYPE                                                  QPM.sub.-- E1.sub.-- BD -                                                     CNFG.sub.-- QPM.sub.-- E1.sub.--                                              BOARD.sub.-- TYPE                                                             QPM.sub.-- T1.sub.-- BD -                                                     CNFG.sub.-- QPME.sub.-- T1.sub.-- BOARD.sub.--             ______________________________________                                                           TYPE                                                   

At this point, the registered hardware in the switching platform isready to begin operation and the resource manager can send messages tothe switching module 16 to add traffic channels or LAP-D channels. Foreach message to add a LAP₋₋ D channel, the CNFG task 50 will process theadd message by locating and assigning a MUNICH32 resource via issuing anailed up connection request to the SWTH task of the CNFG task 50. Table330 shown below and in FIG. 12B contains field 332, which is an array ofcontrol channels used to communicate with a BTS.44. Field 332 isaccessed via the config₋₋ ptr 324 field of the configuration database260.

    ______________________________________                                        Field Name  Field Type    Comments                                            ______________________________________                                        BTS.sub.-- Control[] (332)                                                                CNFG.sub.-- BTS.sub.-- CON-                                                                 An array of (NUM.sub.--                                         TROL.sub.-- TYPE                                                                            BTS.sub.-- CONTROL.sub.--                                                     CHAN) elements                                                                containing BTS.sub.--                                                         control channel                                                               assignment data.                                    ______________________________________                                    

BTS₋₋ Control channels (sometimes specifically referred to as MUNICHchannels because of the SIEMENS-proprietary Munich integrated circuitsused in an embodiment of the present invention) are used to communicatewith the BTS 44. This communication path is provided, for example,through an Abis interface and implemented with a LAP-D protocol. EachBTS₋₋ CONTROL channel may be associated with one timeslot 46 of ahigh-speed bus 25. The contents of field array 332 is shown below and astable 380 in FIG. 12B.

    ______________________________________                                        Field Name                                                                            Field Type    Comments                                                ______________________________________                                        LCI     UINT4         LCI of the interface module 20                          (382)                                       trunk connected to this                                 BTS.sub.-- CONTROL channel.                             Sapi    UINT2         Initial SAPI used by the LAP-D                          (384)                     task to establish the control link.                 Tei     UINT2         Initial TEI used by the LAP-D                           (386)                    task to establish the control                                              link.                                                   Timeslot                                                                              UINT2         Physical timeslot 46                                    (388)                 associated with the LCI                                 Con     PHYS.sub.-- CKT.sub.-- TYPE                                                                 MTSL line & slot information                            (390)                                                for the PCM                                    timeslots asso-                                                               ciated with this BTS.sub.-- CONTROL                                           channel.                                                ______________________________________                                    

If a signal processing module 22 checks in with the switching module 16and, for example, a traffic channel is added, then the CNFG task 50updates table 340 shown below and in FIG. 12B. Each signal-processingmodule 22 preferably contains 1 to 4 daughter boards 242, with eachdaughter board 242 containing two DSPs 240. The DSPs 240 are used toprovide GSM encoding and are mapped into, for example, GSM₋₋ ABIStraffic channel circuits. Each DSP 240 is individually controllable.CNFG task 50 will statically allocate space for the maximum number ofthese structures needed. The table 340 is accessed through the config₋₋ptr field 324 of the configuration database 260.

    ______________________________________                                        Field Name Field Type Comments                                                ______________________________________                                        Dsp.sub.-- mask (342)                                                                    UINT1      Mask indicating which DSPs                                                    240 are installed.                                      Tot.sub.-- installed.sub.-- dsps                                                         UINT1      Total number of DSPs 240                                (344)                 installed on this                                                             signal-processing module 22 board.                      Free.sub.-- dsps (346)                                                                   UINT1      Number of DSPs 240 re-                                                        maining to be used.                                     Faulted.sub.-- dsps (348)                                                                UINT1      Number of faulted DSPs 240.                             Dsp[] (350)                                                                              CNFG.sub.-- DSP.sub.--                                                                   A two dimensional array 350                                        RESOURCE.sub.--                                                                          used to access the                                                 TYPE       DSPs 240 [MAX.sub.-- SPM.sub.--                                               DAUGHTER.sub.-- BDS]                                                          [MAX.sub.-- DSP.sub.-- PER.sub.--                                             DAUGHTER.sub.-- BD]                                     ______________________________________                                    

Each DSP 242 is indexed in the table 340 via dsp[ ] field 350. Thus,field 350 would have eight array entries, one for each DSP 242 on thesignal processing module 22, the organization and content of the arrayfor eacg DSP 242 shown below as table 400 and in FIG. 12B. As shown intable 400, for each DSP 242, a LCI is generated by the CNFG task 50 andstored in field 402. As each DSP utilizes five timeslots, five physicaladdress locations on a pcm bus are stored in fields 408 and 410 Forexample, field 408 contains the physical circuit assigned to the DSPconnection handling GSM encoded channels 49 and field 410 provides anarray of the physical circuits assigned to the DSP connection handlingthe four resultant PCM encoded lines channels 48. Also shown in table400 is field 406, which contains the span 40 that has been nailed up tothe DSP 242 when a traffich channel was added. Field 406 contains theLCI of the appropriate span 40.

    ______________________________________                                        Field Name                                                                              Field Type    Comments                                              ______________________________________                                        DSP.sub.-- lci (402)                                                                    UINT4         Provides the LCI of the                                                       particular DSP 242.                                   State (404)                                                                             UINT1         DSP.sub.-- ALLOCATED,                                                         DSP.sub.-- INSTALLED,                                                         DSP.sub.-- TEST,                                                              DSP.sub.-- FAILED,                                                            DSP.sub.-- NOT.sub.--                                                         PRESENT                                               QSM.sub.-- trunk.sub.-- lci                                                             UINT4         QSM trunk that has been                               (406)                   `NAILED-UP` to this                                                           DSP 242.                                              GSM.sub.-- ckt                                                                          PHYS.sub.-- CKT.sub.-- TYPE                                                                 High-speed bus 25 and                                 (408)                   timeslot information for                                                           the GSM-encoded timeslot                                                 associated with the                                                           particular DSP 242.                                   PCM.sub.-- ckt[]                                                                        PHYS.sub.-- CHT.sub.-- TYPE                                                                 An array 410 of                                       (410)                   MAX.sub.-- TCH.sub.--                                                         ENCODED.sub.-- PER.sub.-- DSP (4)                                             elements 440 containing                                                       high-speed bus 25 and                                                         timeslot information for                                                      the PCM timeslots                                                             associated with the DSP.                              ______________________________________                                    

When a telephony support module 18 registers with the switching module16, the CNFG task 50 maintains the pcm line that is associated with themodule 18 as shown below in table 360 and in FIG. 12B. CNFG 50 willstatically allocate space for the maximum number of these structuresneeded. Table 360 is accessed through the config₋₋ ptr 324 field of theconfiguration database 260.

    ______________________________________                                        Field Name                                                                             Field Type                                                                              Comments                                                   ______________________________________                                        PCM.sub.-- line                                                                        UINT1     High speed bus 25 used by this board.                      (362)                                                                         ______________________________________                                    

The resources provided by the telephony support modules 18 are furtheridentified by LCIs according to an embodiment of the present invention.For instance, a LCI would be provided for a dial tone, which would be aresource provided by the one of the DSPs 226 (see FIG. 10). As before,this LCI identifies a timeslot 46 that exists on the high-speed bus 25to which the telephony support module 18 is connected. In the embodimentof FIG. 2, the high speed bus 25 that is dedicated to thetelephony-support modules 18 is bus 1. More than one of the trafficchannels being switched by the switching platform 10 may need to beconnected to a particular resource. For example, more than one of thetraffic channels may need to hear a busy signal or ring signal at aparticular time. Accordingly, the switch 43 is operable to connect thetime slot carrying such signals to multiple traffic channels asinstructed by the switching module controller 156.

Other resources provided by the telephony support module 18 includeresources for decoding and transmitting signaling information that isused to form connections between information channels. The DSPs 226 ofthe telephony support module 18 will preferably provide a pool of suchresources on various timeslots 46 of the high-speed bus 25 between theswitch 43 and the telephony support module 18. These resources will bedynamically assigned, based on availability, to the traffic channelsneeding such resources.

When an interface module 10 registers with the switching module 16, thefield 324 will be cast to field 372, as shown in FIG. 12B, and CNFG task50 will update field 372, which is an array of spans (e.g., E1s)contained in an interface module 20 (e.g., there are four spans on eachmodule 20). Also, there will be a table 370 for each interface module20. The span interface modules 20 preferably interface to E1-standardspans 40. An interface module 20 preferably contains 1 to 4 spans 40,with each span 40 being individually controllable.

    ______________________________________                                        Field Name                                                                            Field Type    Comments                                                ______________________________________                                        span[] (372)                                                                          CNFG.sub.-- SPAN.sub.-- TYPE                                                                This field is an array 372 of                                                 CNFG.sub.-- SPAN.sub.-- TYPE, containing                                      MAX.sub.-- QSM.sub.-- SPANS.sub.-- BD                                         (4) elements 420.                                       ______________________________________                                    

The CNFG task 50 can support, for example, land spans 40 and GSM airspans 40. The content of each array field 372 is shown in table 420belowand in FIG. 12B. As shown in the table 420, each span 40 has a uniquelogical identifier or "LCJ" field 422, type field 424, state field 426,physical circuit array 428, and logical circuit array (air circuitsonly) 428. Defined types 424 comprise, for example: SPAN₋₋ NONE, SPAN₋₋GSM₋₋ ABIS, or SPAN₋₋ PSTN. SPAN₋₋ NONE, indicates no physicalconnection to a interface module 20 for a particular span input. Aspan's state 426 may be ENABLED, DISABLED, or FAULTED. The state of asingle span 40 does not affect other spans on the same board 40.

Air spans 40 (e.g., GSM₋₋ ABS) use both the logical and physical circuitarrays. Air span circuits map 4 to 1 within one of the timeslots of anexemplary high-speed bus 25. Thus, the logical circuit array 428 ispreferably an array containing 128 entries 440. These logical LCIentries 440 are referenced by the Resource Manager. The physical circuitarray 430 preferably contains 32 entries and is used for interfacemodule 20 to DSP 242 mapping. This array 430 is used to translate LCIvalues from the Resource Manager to high-speed bus 25 and timeslotinformation. Land spans (e.g., PSTN spans) preferably map directly tophysical circuits, in which case only the physical circuit array 430 isneeded. These LCI entries are referenced by the Resource Manager. Thisarray 430 is used to translate LCI values from the Resource Manager tohigh-speed bus 25 and timeslot 46 information.

    ______________________________________                                        Field Name                                                                            Field Type                                                                             Comments                                                     ______________________________________                                        LCI (422)                                                                             UINT4    LCI that identifies the particular span 40.                  Type (424)                                                                            UINT1    Span types:                                                                    SPAN.sub.-- NONE                                                              SPAN.sub.-- PSTN                                                              SPAN.sub.-- GSM.sub.-- ABIS                                 State (426)                                                                           UINT1    ENABLED - span 40 is present at the interface                                  module 20 and is ready for use.                                              DISABLED- span 40 is present, but disabled                                    FAULTED- span 40 is present, but faulted                     ______________________________________                                    

    ______________________________________                                        Logical.sub.-- ckt[]                                                                   CNFG.sub.-- PHYS.sub.-- CKT.sub.--                                                           An array 426 of                                       (426)    TYPE           MAX.sub.-- GSM.sub.--                                                         ENCODED.sub.-- TIMESLOTS                                                      elements 440 representing                                                     the logical 4 to 1                                                            mapping of air circuits.                                                      Not used for land circuits.                           phys.sub.-- ckt[]                                                                      CNFG.sub.-- PHYS.sub.-- CKT.sub.--                                                           An array 428 of MAX.sub.--                            (428)    TYPE           2M.sub.-- TIMESLOT elements                                                   440 representing the physical                                                 timeslots for this span 40.                           Dsp.sub.-- lci[]                                                                       UINT4          An array 430 of MAX.sub.--                            (430)                   2M.sub.-- TIMESLOT elements                                                   440, indicating the LCI                                                       of the DSP 442 "nailed"                                                       to this timeslot. Preferably,                                                 this field is only used                                                       for GSM spans.                                        ______________________________________                                    

Still referring to FIG. 12B, tables 440 are used as the lowest level inthe configuration database 52 and provide the pcm bus values. Forexample, each table 440 provides the high-speed bus 25 and timeslot aspecified circuit is mapped to.

    ______________________________________                                        Field Name                                                                            Field Type                                                                             Comments                                                     ______________________________________                                        Line (442)                                                                            UINT1    High-speed bus 25 number, preferred range is                                  0 - 15.                                                      Slot (444)                                                                            UINT1    Timeslot number within a particular high-speed                                bus 25, preferred range is 0 - 127.                          Type (446)                                                                            UINT1    circuit type                                                 ______________________________________                                    

FIG. 13 is an exemplary flow chart describing how LCIs according to anembodiment of the present invention are used to configure communicationswithin the telecommunications switching platform 10. The process beginsat step 460, where, for example, the resource manager provides a LCI tothe SWTH task which in turn calls the Cnfg Lci Xlation process of theCNFG task 50. At step 462, the switching module 16 uses the LCI toextract the slot, span, and board₋₋ type that is associated with theLCI, for example, using the GET macro described previously.

At decision step 464, if the slot provided within the LCI exceeds themaximum number of slots in the backplane of the telecommunicationsswitching platform, then the switching module 16 would note that this isan invalid slot and would return that result at step 466 (INVALID SLOT).If, however, the slot number was in the permissible range for of aparticular telecommunications switching platform, the switching module16 at step 468 compares the provided board₋₋ type from the LCI to thetable of board₋₋ types that are in use in that particulartelecommunications switching platform. If the board₋₋ type provided inthe LCI is not a board type used in the particular telecommunicationsswitching platform 10, the process at step 470 returns that result fromthe process (INVALID BOARD) .

Now, if the board₋₋ type was one of the permissible types of boards forthat particular telecommunications switching platform, the processproceeds to follow different paths depending on which type of board wasidentified by the particular LCI. At step 472, if the board₋₋ typecorresponds with that for a telephony support module 18 (sometimesreferred to as a PCM-Support Module or "PSM"), then the process willcontinue at step 474. If, on the other hand, the board₋₋ typecorresponds to an interface module 20, the process at step 480 willproceed to step 500, which is identified by the "A" branch (see FIG.13B). If the board₋₋ type is neither the telephony support module 18 oran interface module 20, the process proceeds to step 482, where theboard₋₋ type is checked to see whether it corresponds with a switchingmodule 16. If the board₋₋ type indicates a switching module 16, theprocess continues to step 550, which is designated by "B," which isshown again at the top of FIG. 13C. If the board₋₋ type is neither atelephony support module 18, nor an interface module 20, nor a switchingmodule 16, then the process continues to step 484, where it isdetermined whether the board₋₋ type corresponds to that associated withsignal processing module 22. If the board₋₋ type does corresponds to asignal processing module 22, the process continues to step 600, which isidentified by "C" and is shown again at the top of FIG. 13D. Since theboard₋₋ type was tested for validity at step 468, the board₋₋ typeshould always be able to be identified by one of the decision blocks472, 480, 482, 484, or a new decision block for a new type of board notspecifically described herein. Step 486 is nonetheless provided as adefault to return an INVALID BOARD message if for whatever reason theprocess proceeds from all the known board₋₋ type decision blocks withoutbranching to the handler for that particular type of board type.

Returning to the manner in which LCIs are handled for each of theparticular board₋₋ types, if the board₋₋ type was that of a telephonysupport module 18, the process continues at step 474. At step 474, theswitching module 16, using the LCI, extracts the circuit identifier, forexample using a GET macro. At step 476, the switching module 16 looks tothe configuration table 52 to find the telephony support module'sassigned high speed bus 25 (sometimes referred to as a PCM-line). Atstep 478, the process returns a high speed bus 25 identifier and theparticular slots used by the telephony support module 18. For example,the circuit identifier extracted from the LCI would be used as an indexinto database 260 illustrated in FIG. 12A to navigate through to thedatabase table 360, which identifies the PCM line used by the module 18.

If the board₋₋ type was that of an interface module 20, the processcontinues at step 500 (FIG. 13B). At step 502, the span identifierwithin the LCI is extracted and tested to see if it is within the rangeof 0-3. This is because in the embodiment of the present invention, theinterface module 20 handles no more than four spans by itself If thespan identifier is outside this permissible range, the process returnsan INVALID SPAN message at step 504. If, on the other hand, the spanidentifier is within the permissible range, the process creates apointer to a data set that associated with the particular span, andextracts the span₋₋ type that is associated with this particular span 40from the data structure at step 506. At decision blocks 508 and 510 itis determined from the span-type information within the configurationtable 52 whether the particular span 40 is a land-based span or an airspan. For example, table 420 for each interface module 20 includes spantype information in field 424. Land-based spans are sometimesspecifically referred to as PSTN spans and air spans are sometimesspecifically referred to as GSM or PCS spans. If at step 508 it isdetermined that the span is a land-based span, the process sets thecircuit-pointer to point to the physical circuit array in theconfiguration table at step 514 (see field 430 of table 420 in FIG.12B). If at step 508 it was determined that the span was not aland-based span, the process would continue to step 510, where thespan₋₋ type would be tested to see whether the span is a GSM-ABIS airspan. In the present configuration, if the span was neither of thesetypes, the process returns an INVALID SPAN message at step 512. If, onthe other hand, it was determined at step 510 that the circuit was anair span, then at step 511 it would be determined if a force physicalbit in the span LCI was set. If the force physical bit was set, theckt₋₋ ptr would be set to the physical circuit in step 513 because thiswould indicate that the nailed up connection for the span was not yetestablished and the physical circuit associated with the span should beused to establish the nailed up connection between the span and itsallocated DSP. If the force physical bit is not set, then at step 518the process sets a pointer to the logical circuit in the configurationtable 52 for the desired traffic channel. Once the pointer has beenproperly set at step 513, 514 or step 518, the process continues at step516 to extract the circuit identification from the LCI. If the circuitis within a permissible range for circuits within that particulartelecommunications switching platform (step 518), the process returnsthat circuit's line and slot information at step 522. If the circuit isoutside the range of permissible circuits, the process returns anINVALID CIRCUIT message at step 520.

If the board₋₋ type corresponds with that for the switching module 16,the process continues at step 550 (FIG. 13C). Here, switching module 16extracts the circuit identification from the LCIs at step 552. If thecircuit identification is within the range of valid control channels,which are sometimes referred to as MUNICH32 channels, the process willaccess at step 556 the configuration table 52 to get to the line andslot information associated with that particular circuit. For example,the switching module 16 LCI would be used to index through database 260to table 330 down to the line and slot fields for the circuit containedin table 440, as shown in FIG. 12B. If, on the other hand, the circuitis outside the range of valid MUNICH32 channels, then at step 560 thecircuit is checked to see whether it is within the range of validconference circuits. If it is, at step 562, the slot is set to "circuit"and the line is set to 0. This line and slot information will bereturned from the process at step 558. If the circuit was outside therange of valid MUNICH channels and valid conference circuits, in thisembodiment the process returns an INVALID CIRCUIT message at step 564.

If the board₋₋ type corresponds with that for a signal processing module22, which is sometimes referred to as an SPM, the process continues atstep 600 (see FIG. 13D). At step 602, the DSP information is extractedfrom the LCI. If at step 604 it is determined that the DSP is within therange of permissible DSPs for the switching platform, (e.g., numberedbetween 1 and 8) the process at step 608 creates a pointer to this SPMboard using the DSP look-up line and slot data from the configurationtable 52. This line and slot information is return from the process atstep 610. If at step 604 the DSP had been outside the range ofpermissible DSP use, the process will returned an INVALID CIRCUITmessage at step 606.

According to an embodiment of the present invention, the interaction ofLCIs, the CNFG task 50 and the CNFG database 52 is now described. Whenan air traffic channel is added (e.g., in response to an ADD₋₋ TCHmessage to make a nailed up connection), the call processor 12 providesa span LCI and a physical timeslot to be used for the connection. Fromthis information, a logical timeslot can be determined. For example, ifthe call processor 12 sends a command, for example via a resourcemessenger to the switching module 16, to add a traffic channel totimeslot 1, a span LCI is provided (which provides the shelf, slot,board type, span (air or land) and a span number) and a physicaltimeslot, e.g., 1. With this information, CNFG task 50 locates a freeDSP for the nailed up connection by going into the CNFG tables,illustrated in FIGS. 12A and 12B and reading field 346 to find a freeDSP. For example, CNFG task 50 searches the configuration databse 52 forall signal processing modules 16 by traversing the board array field 278and reading field 304 for each board to determine its type. For eachsignal processing module identified, the CNFG task 50 reads field 346 todetermine if a free DSP exists. If field 346 indicates that a free DSPexists, the CNFG task 50 would search array field 350 for each DSP onthe signal processing module 16, reading field 404 for each DSP todetermine if the DSP is free until the free DSP is located. The DSParray 350 for the free DSP also includes fields 402-410 as shown in FIG.12B.

Field 408 identifies the encoded GSM connection of the DSP, e.g., thepcm bus line and slot contained in fields 442-446 as shown in FIG. 12B,for the nailed up connection. Field 410 includes an array of the decodedGSM connections of the DSP namely the pcm line and slot for eachconnection of the free DSP that provides a DS0 for a single voiceconnection. Thus, the line and slot for the encoded GSM connection forthe free DSP provides one connection point on the swiching module 16,the other connection point being the LCI of the span provided by thecall processor 12. Accordingly, a nailed up connection is made betweenthese points.

As shown in FIG. 12B, the LCI of the span for the nailed up connectionto the free DSP is inserted into field 406 (which is in table 400 forthe free DSP now assigned to the nailed up connection) and representsthe span and physical timeslot the DSP is connected to. Similarly, thespan array 372 contains fields 422-432 for each span. Field 432 containsthe LCI of the free DSP now being used for the nailed up connection tothe span. Field 430 in the span array 372 represents the physicaltimeslot used for the nailed up connection that is connected via theswitching module 16 to the physical circuit identified in field 408 ofthe DSP table 400 thus providing the nailed up connection. If the nailedup connection is for a land span, then field 430 provides the physicaltimeslot used to process a call through the switching platform 10.However, if the nailed up connection is for an air span, indicated infield 424, then for call processing on the span, the physical timeslotfield 430 is used only for establishing the nailed up connection andactual call processing (e.g., the voice connection for a call) uses thelogical timeslot field 428. With reference to FIG. 14, each interfacemodule 20 can support four spans, each span providing 32 physicaltimeslots (e.g., DS0s) numbered 0-31. An exploded view of span I in FIG.14 illustrates the 32 physical timeslots on the span, which could beused, on a land span, to support a 32 traffic channels. However, if thespan is an air span, then each physical timeslot, which is a 64 kbpsDS0, can support 4 16 kbps GSM traffic channels and thus there are 128logical timeslots for each span (each of the 32 physical timeslotssupport 4 GSM channels), the logical timeslots being numbered 0-127 asshown in FIG. 14. Accordingly, a logical timeslot is determined by thespan and physical timeslot. For example, on span 1, physical timeslot 1,logical timeslots 4, 5, 6 and 7 are available and can be addressed viathe logical circuit array 428, each logical circuit being assigned a pcmline and slot in fields 442-446 as shown in FIG. 12B

The tables 440 including fields 442-446 contain the pcm bus values andare based, for example, on the hardware layout information stored in atable in the switching module 16 that associates the pcm line and slotdata with the component assigned to the timeslot. Fields 442-446 areinitially set to a null value for the logical timeslots until airtraffic channels are added, which are added four at a time. When the airchannels are added, the line and slot for each logical circuit stored inarray field 428 will correspond to the four decoded GSM connections forthe associated DSP stored in array field 410 of DSP table 400 for theparticular DSP.

Once a nailed up connection is established, the nailed up DSP LCI fromdsp₋₋ lci field 402 goes in the dsp₋₋ Ici array field 432 for the spanof the nailed up connection (e.g., each timeslot on a span could be atraffic channel assigned a unique DSP). Similarly, the LCI of the spanof the nailed up connection is put in field 406 of the DSP table 400, asshown in FIG. 12B.

If a DSP is to be reallocated because, for example, the DSP has failed(e.g., the board detects that a DSP is not responding to a pollingsignal), the board containing the DSP has been removed from the systemor a test such as built in test (BIT) determines that the DSP is bad,then the DSP can be replaced by an operational DSP via a remappingoperation according to an embodiment of the present invention. Theremapping can be done as long as there is an available DSP to assume thefunctions of the failed or missing DSP. For example, to remap a DSP (orany other component that may have spare components available) accordingto an embodiment of the present invention, the resource manager and thusthe call processor 12, is told by, for example, the CNFG task 50 that aparticular DSP is out of service. As explained earlier, the LCI of thespan connected to the bad DSP to can be provided to the resource managerby CNFG task 50. This LCI would include the span and the physicaltimeslot used for the nailed up connection, which identifes the GSMencoded connection to the DSP (e.g., the physical circuit identified infield 408 of table 400 for the DSP) from which the four traffic channels(e.g., the decoded GSM connections of the DSP identified in array field410 in table 400 for the DSP) can be identified. With this information,the resource manager informs the call processor 12 that the four trafficchannels allocated to the failed DSP are out of service. Once thetraffic channels are out of service, the switching module 16 willattempt to locate a free DSP. For example, the CNFG task 50 will readfield 346 of the DSP table 340 to determine if there is a free DSP andthen determine the LCI of the free DSP as explained previously. If afree DSP cannot be located, no further action is taken to remap theconnections to the failed DSP and the affected traffic channels remainout of service.

However, if a free DSP is located, a move traffic channel (MOVE TCH)message is sent to the SWTH task which, for example, takes the LCI ofthe span connected to the bad DSP, the LCI of the bad DSP and the LCI ofthe new DSP and moves the connection in the switching module 16 of theaffected span to the new DSP and will then break the connection betweenthe affected span and the bad DSP. Once the new connection isestablished, the resource manager is then told that the affected trafficchannels are now available, the resource manager informing the callprocessor 12 that the traffic channels are back in service. The MOVE TCHmessage involves, for example, the following changes to the CNFGdatabase 52 illustrated in FIGS. 12A and 12B. The qsm₋₋ trunk₋₋ lcifield 406 in the DSP table 400 for the new DSP will be updated tocontain the LCI of the span (e.g., the span does not change and the LCIof the span is put in the database for the remapped DSP).Correspondingly the dsp₋₋ lci[ ] field 432 in the span table 420 for thespan will be updated with the LCI of the new DSP. In addition, as a newDSP has been mapped to the span, the new LCIs for the physical circuitconnection to the new DSP and the logical circuits (e.g., four for everyphysical circuit) must be provided to the configuration database 52 forthe span. Accordingly, the decoded DSP pcm line and slot data for thenew DSP of field 410, contained in fields 442-446 of field 440 of thenew DSP will be copied into the logical₋₋ ckt array 428 of the affectedspan, e.g., the four traffic channels associated with the four logicalcircuits in the affected span will be replaced with the circuits of thenew DSP that will handle the traffic channels.

Therefore, the failed DSP has been dynamically remapped to allow a newDSP to assume the functions of the failed DSP and further, all of thechanged connections remained transparent to the call processor 12. Forexample, the LCIs of the spans were not changed nor were the trafficchannels assigned to each span and thus no additional processing wasrequired by the call processor 12 due to the remapping process.Utilizing a configuration database 52 according to embodiments of thepresent invention, for example as illustrated in FIGS. 12A and 12B,allows for dynamic reallocation of resources. For example, if aninterface module 20 was removed from the switching platform 10, usingthe same process as described above, the DSPs associated with theaffected traffic channels (which are not affected by the removal of theinterface board 20) can be readily identified and returned to the freepool to provide additional available DSP resources to the switchingplatform 10.

According to an embodiment of the present invention, fault testing isperformed during operation of the switching platform 10 to detect,report and compensate for switch circuit errors before a call is placedon a faulted path. The fault testing has, for example, two modes--anautomatic mode and a manual mode. The automatic mode is referred to asbuilt in testing (BIT) and the manual mode is referred to as faultisolation testing (FIT). In the automatic mode, BIT will, for example,cycle continuously while the switching platform 10 is operational totest, for example, resource processors 18, 20, 22 or spare DSPs. If theproper test tone is not detected in BIT, then a localization procedurewill be executed to attempt to isolate the failed component (e.g.,interface module board 20, signal processing board 22 or DSP). While BITruns automatically, is nondestructive and can establish and tear downthe connections necessary to conduct the testing, FIT is manuallyinitiated, destructive and utilizes existing connections for the test.BIT and FIT, however, are functionally equivalent in the execution ofthe actual testing, as explained in more detail below. Thus, BIT and FITinclude a localization procedure to isolate, for example, a faultyreplaceable component.

BIT is a stand alone task that resides on the switching module 16 andinteracts with various other tasks, such as CNFG task 50 in FIG. 6. Theprimary function of the BIT task is to schedule and execute a series ofcontinuous tests. The BIT task can be, for example, a low priority taskthat schedules tasks at a relatively slow rate to insure minimal systemimpact. For example, the tests can be scheduled so that every 5 secondsa continuous test will execute. Different types of continuous tests canbe defined. For example, according to an embodiment of the presentinvention there is a Board Loop continuous test and an Idle DSP Loopcontinuous test.

The BIT task will interface to, for example, the resource manager, theCNFG task 50, the SWTH task and the RLPD task, the interface beingimplemented, for example, by the use of pSOS mailboxes. To determine theboards or components to test, the BIT task reads the configurationdatabase 52 to determine the boards (e.g., resource processors 18, 20,22) that are registered with the switching module 16. For each resourceprocessor 18, 20, 22, the BIT task is coded to request that theappropriate boards or components be tested. The tests performed by BITand FIT are described in more detail below.

While the resource manager can command a redundant fail-over of variousboards in the switching platform 10 (e.g., the telephony support module18 or the switching module 16), the BIT task can generate an alarm to betransmitted to the CNFG task 50 that may result in an automaticfail-over of a board that has failed BIT. When the switching module 16is initialized, the BIT task initializes itself to an automatic testingmode and resets the test database maintained by the BIT task. The testdatabase is used by the BIT task to track the boards or circuits thathave already been tested by BIT.

For example, if a DSP fails BIT, the result of the test (e.g., failedDSP) is stored in the BIT database. An alarm is sent by the BIT task toCNFG task 50 as a result of the failed test and the CNFG task 50 resetsthe DSP and changes the state of the DSP to failed in the configurationdatabase 52. The DSP may be revived, however, due to the reset and willbe tested again by the BIT task (as all idle DSPs will be testedcontinuously, even if the state of the DSP is failed). If the DSP passesa subsequent BIT test, the state of the DSP in the configuration can bechanged to an operable state (e.g., a free DSP) if predetermined numberof BIT tests are passed, which can be tracked by the BIT task testdatabase. Thus, the testing according to an embodiment of the presentinvention allows failed components to be continuously identified evenduring operation of the switching platform and also provides fordynamically returning the failed component to service.

In order to carry out the testing, the BIT task generates severaldifferent types of messages as the test circuits have to be establishedfor a particular BIT to be performed. For example, the BIT task sends aplay₋₋ tone₋₋ request signal to the SWTH task to generate, for example,SIMPLEX connections between the requested tone (from a tone generator onthe telephony support module 18) and the time slot being tested. Inresponse, BIT receives a play₋₋ tone₋₋ rsp message, indicating if thespecified BIT connection was made. A tone₋₋ detect₋₋ req message is sentto, for example, the tone detector on the telephony support module 18 tostart the tone detector on the specified time slot and includes the toneID of the tone to be detected (e.g., DTMF). In response, BIT receives atone₋₋ detect₋₋ rsp message, indicating if the applied tone was detectedand including the ID of the tone being used. An internal₋₋ simplex₋₋ reqmessage is sent by the BIT task to the SWTH task for making theconnections between the tone detector timeslot and the tone generatortimeslot on the switching module 16 during a fault isolating analysis.

The BIT task sends a bit₋₋ loop₋₋ req message to the LCOM task forforwarding to the proper resource processor 18, 20, 22, this messagecontaining, for example, the MUSAC chip loop connection requests (e.g.,for making or breaking the loop) needed for real time loop connectionsfor particular resource processors 18, 20, 22. A MUSAC chip refers to aSIEMENS integrated circuit that is acts as a switch that can combine,for example, four 2 MHZ buses into one 8 MHZ bus. For example, the MUSACchip on the telephony support module 18, interface module 20 or signalprocessing module 22 can assign each timeslot of each 2 MHZ bus to atimeslot on the 8 MHZ bus. In response to the bit₋₋ loop₋₋ req message,the BIT task receives a bit₋₋ loop₋₋ rsp message indicating whether ornot the connection was successful. A bit₋₋ psm₋₋ loop₋₋ req message issent by the BIT task to the LCOM task for forwarding to the propertelephony support module 18, this message containing the MUSAC loopconnection requests that will be performed by the telephony supportmodule 18. For example, the message would contain the LCI of the circuitto loop, the type of action (e.g., make or break connection) and whetherthe loop connection is on the 2 MHZ or 8 MHZ side of the MUSAC chip.

FIG. 15 illustrates nailed up loop connections on a MUSAC chip 21 for aninterface module 20 or signal processing module 22 that areautomatically established on initialization of the respective board.Accordingly, the MUSAC chip 21 can be used to establish nailed up loopconnections in available timeslots, for example using timeslot 0 on eachspan of the interface module 20 (which is not used in an embodiment ofthe present invention for call processing) or the free timeslots on thesignal processing module 22 (as there are 8 free timeslots that are notused by the three signal processing modules 22 that are assigned to thePCM bus).

When a component is identified for testing, for example a DSP, the BITtask sends a bit₋₋ dsp req message to the CNFG task 50 for removing therequested DSP from the free list (see FIG. 12B, table 340) and alsoignoring any other alarm messages that CNFG task 50 might receive fromtasks other than BIT. A similar message exists for FIT. The bit₋₋ dsp₋₋req message includes, for example, the LCI of the DSP to be tested. Inresponse to the bit₋₋ dsp₋₋ req message, the BIT task receives a bit₋₋dsp₋₋ rsp message from the CNFG task 50 indicating whether or not therequested DSP can be tested (e.g., whether the requested DSP is free oris being used in a nailed up connection). FIT has a similar message.After testing, the bit₋₋ free₋₋ dsp message is sent by the BIT task toCNFG task 50 to put the DSP back in its original state (e.g., free, ifBIT passed) or to change the state of the DSP to faulted (e.g., if BITfailed). A similar message exists for FIT. The BIT task will generate analarm message for any detectable but nonrecoverable conditions that areencountered. Alarm messages are sent to the CNFG task 50 and arereported to the resource manager or call processor 12 and may result ina fail-over to a redundant component.

A fit₋₋ test₋₋ req message causes the BIT task to execute FIT on thespan LCI specified in the message. As this is FIT, the test isdestructive and the circuit to be tested cannot be in service (and thusthe span must be taken off-line prior to the test). A fit₋₋ test₋₋ rspmessage is generated to report the results of a specific FIT previouslyrequested by the resource manager and would include, for example, theLCI of the element for which redundant fail-over is requested.

As mentioned above, two types of continuous tests are used in anembodiment of the present invention--board loop and idle DSP loop. FIG.15 illustrates an exemplary block diagram for a board loop testaccording to an embodiment of the present invention and FIGS. 16A-16Billustrate an exemplary flowchart for performing a board loop test. Asshown in FIG. 15, a board loop test involves a telephony support module18 including a tone generator 191 and a tone detector 192. The tonegenerator 191 generates the tone requested by the BIT task, such asDTMF, while the tone detector receives and evaluates the test tone.Board loop tests will use nailed up test loop connections in, forexample, the MUSAC chip 21 on each resource processor 18, 20, 22. Asmentioned above, the nailed up connections 23 on the MUSAC chip 21 areestablished at initialization of each resource processor 18, 20, 22using a data table in each resource processor identifying the timeslotsto be used for the nailed up connection. Thus, for example, there wouldbe four nailed up test loop connections for each interface module board20 (e.g., one for each timeslot 0 on each span of an interface module20) and a test tone would be applied to timeslot 0 on each span. As isknown in the art, the test loop includes connecting the transmit path tothe receive path on the timeslot to be used for the nailed upconnection. According to an embodiment of the present invention, testingfor both BIT and FIT includes, for example, a loopback test in which atone is connected to the tested circuit and the tested circuit is loopedback to a tone detector to evaluate the received tone. For example, BITcould include applying a loopback connection to timeslot 0 on each spanof an interface module 20.

FIGS. 16A-16B illustrate exemplary steps to test an interface module 20or a signal processing module 22 according to an embodiment of thepresent invention. The test tone generator 191 is connected to the inputof the test loop in step 1600 via the switching module 16 (path a) tothe nailed up connection 23 to be tested. The test tone provided to thetest loop is a specific type of tone determined by the BIT task and thespecific tone must be detected in order to pass the test. In step 1602,the tone detector 192 is connected to the output of the test loop, viathe switching module 16 (path b), to the nailed up connection 23. Instep 1604, if the proper test tone is detected, then the result of thetest is a PASS and the BIT terminates for the test loop. If no tone orthe wrong tone is detected in step 1604, the result of the test is aFAIL and then a localization procedure is invoked in step 1606.

In step 1610, the test loop is moved back and inserted at the switchingmodule 16 indicated by path c in FIG. 15. For example, as shown in FIG.15, the connection paths in the switching module 16 are connected via aloop and at step 1612, the test tone is applied (e.g., the test tone isavailable when the loop at the switching module 16 is installed). If theproper test tone is detected at step 1614, then the fault has beenisolated and the resource processor (e.g., the interface module 20 orthe signal processing module 22) is identified as bad, an alarm isgenerated and the BIT task terminates. If no test tone or the wrong testtone is detected in step 1614, then the test loop is moved back to thetelephony support module 18 in step 1618, for example by connecting thetone generator 191 to the tone detector 192 using the connection pointof each device on the switching device 16 indicated by path d. The testtone is applied to the test loop at step 1620 and the test tone isdetected at step 1622. If the proper test tone is detected, then thefault is isolated at step 1628 and the switching module 16 is identifiedas bad. Since there is a redundant switching module 16 in an exemplaryembodiment of the present invention, then in step 1630, an alarm messageis sent by the BIT task to CNFG task 50 that may result in a fail-overto the redundant (e.g., off-line) switching module 16. If no test toneor the wrong test tone is detected in step 1622, then the fault isisolated at step 1624 and the telephony support module 18 is identifiedas bad. Since there is a spare telephony support module 18 in anexemplary embodiment of the present invention, then in step 1626 analarm message is sent by the BIT task to CNFG task 50 that may result ina fail-over to the redundant (e.g., off-line) telephony support module18.

FIG. 17 illustrates the connection path for an idle DSP loop testaccording to an embodiment of the present invention. As shown in FIG.17, a telephony support module 18 includes a tone generator 191 and atone detector 192. The tone generator 191 provides a tone to a MUSACchip 21 which in turn connects to the switching module 16. The switchingmodule 16 connects the test tone to a signal processing module 22. Asshown, the test tone is received by the MUSAC chip 21 on the signalprocessing module 22 which provides the test tone to the idle DSP to betested. The MUSAC chip 21 connection to the DSP is via a nailed upconnection that is established at the time the signal processing module22 is initialized.

FIG. 18 illustrates an exemplary flow chart for an idle DSP loop testaccording to an embodiment of the present invention. In step 1700, anidle DSP is located, for example a spare DSP on a signal processingmodule 22 in the manner described previously regarding navigationthrough the configuration database 52 and the remapping of failed DSPs.Once an idle DSP is located, a test loop is inserted on the encodedconnection of the DSP (e.g., the connection where the GSM encoded line48 is provided to the DSP) thereby connecting the transmit channel tothe receive channel. In step 1704, a test tone is applied to a receivesside of one of the four decoded connections of the DSP (e.g., the DSPconnection where a pcm line 49 is output by the DSP). The test tone isprovided, for example, by a tone generator 191 on the telephony supportmodule 18. In step 1706, a tone detector is connected to a transmit sideof the same decoded DSP connection. The test tone detector includes, forexample, a tone detector 192 on the telephony support module 18. Thetest tone thus passes through the DSP, loops through the encoded DSPconnection due to the inserted test loop, and is output through thesecond of the decoded connections of the DSP. The tone output from theGSM encoded connection of the DSP is then evaluated in step 1708 todetermine if the proper tone is detected. If the proper tone is detectedin step 1708, the test is passed for the particular decoded DSPconnection in step 1714 and the testing procedure is repeated in step1716 for each of the four decoded DSP connections on the idle DSP beingtested. If the proper tone is not detected in step 1708, then the testfails in step 1710 and in step 1712 a localization procedure isinitiated. If the DSP fails BIT, the localization procedure should berun to ensure that the fault has been isolated to the DSP as the faultmay actually be in one of the boards in the test tone connection path.Thus, the localization procedure verifies that the DSP is bad orisolates the faulty board. The localization procedure is the same asillustrated in FIGS. 15 and 16A-16B for the board loop test, althoughthe initial test loop connection on the MUSAC chip 21 of the signalprocessing module 22 for the idle DSP loop test is a real timeconnection determined as a function of the idle DSP being tested andthus does not use the dedicated nailed up connection of the MUSAC chip21 used for board BIT as described regarding FIG. 15.

Similar to BIT, FIT also isolates faulty components or resourceprocessors using loopback testing with test tones, although with FIT thecomponent being tested is off-line and the connection path for the testloop is already established and does not have to be established as isdone with BIT except for the switching needed for tone generation anddetection. Like BIT, FIT involves, for example, applying a test tone iseach loopback connection and if the loopback connections fail the testtone evaluation, then the fault has not yet been isolated and theloopback connection is moved back a level in the connection path untilthe fault is isolated or it is determined that there is no problem inthe connection path and any problems reside outside of the switchingplatform. As mentioned above, according to an embodiment of the presentinvention, FIT is only run as a result of manual intervention andrequires that a span to be tested be in a nonoperational state and thata loop be physically installed on the span for testing.

FIG. 19 illustrates a connection path for an air span FIT. For an airspan FIT, real time switching within the switching module 16 toestablish tone generation and detection and possibly the interfacemodule 20 MUSAC circuit is required. The air span FIT insures that allassigned traffic channels on the span are tested. If the supplied toneis not detected, then localization will be automatically performed. Inorder to perform FIT according to an embodiment of the presentinvention, a jumper must be placed on the span to be tested to connectthe transmit and receive paths of the span. Once the jumper is in place,then a message will be sent to the switching module 16 (e.g., from thecall processor 12 or resource manager) by the BIT task requesting thatFIT be performed and providing the LCI of the span to be tested. Asdiscussed previously, the CNFG task 50 can translate the LCI via theconfiguration database 52 to determine the lines and slots of the spanto be tested.

As shown in FIG. 19, for an air span FIT, the connections for the testtone are from a test tone generator on the telephony support module 18to a MUSAC chip 21 of the telephony support module 18 to the switchingmodule 16. The test tone then proceeds to a MUSAC chip 21 of the signalprocessing module 20 and then to a DSP on the signal processing module20 which loops the test tone back to the switching module 16. Theswitching module 16 then connects the test tone to a MUSAC chip 21 of aninterface module 20 which in turn connects to the span being tested. Thereturn trip of the test tone from the span being tested follows the samepath in reverse as indicated by the arrows in FIG. 19. To start FIT, thecall processor 12 or resource manager (upon manual instruction) sends afit₋₋ test₋₋ req message with the LCI of the span to be tested. As theinitial test loop for FIT is a jumper on the span to be tested, allchannels of the span are looped (e.g., the receive path is connected tothe transmit path for all 32 channels on the span and the test tone isapplied to each timeslot individually). If the test tone is detected foreach assigned traffic channel on the span, then the switching platform10 circuits are operational and any problems lie outside of theswitching platform 10. If the test tone is not initially detectedthrough the entire connection path illustrated in FIG. 19, however, thenfault isolation according to an embodiment of the present invention mustbe performed.

As shown in the exemplary flowchart of FIGS. 20A-20C, after it isdetermined that the test tone on the initial loop has not been detected,then the test loop is established at point A on the interface moduleboard 20 MUSAC chip 21 at step 2100, the test tone generator and tonedetector are connected at steps 2102 and 2104 (e.g., as a result ofmoving the test loop to point A) and the test tone is applied. As isapparent, the test loop is moved by connecting the transmit and receivepaths on the pcm bus 25 timeslot assigned to MUSAC chip 21 of theinterface module 18 for each channel of the span being tested. Incontrast to the initial test loop, which looped all of the channels ofthe span at once, once the test loop is moved back, each traffic channelon the span is looped and tested individually. Therefore, the stepsdescribed in FIGS. 20A-20C are performed for each traffic channel on thespan. If the test tone is detected by the test tone detector 192 on thetelephony support module 18 at step 2106, then the test result is PASS,there are no problems with the circuits of the switching platform 10 andFIT terminates. If no test tone or the wrong test tone is detected,however, then the test result is FAIL and the fault must be localized atstep 2110. Accordingly, in step 2112, the test loop is moved back topoint B shown in FIG. 19 on the switching module 16.

At point B a loop connection is made between the transmit and receivepaths for the tested channel on the switching module 16. If the testtone is detected at step 2114, then it is determined that the span onthe interface module board 20 being tested is bad and an alarm is sentto the CNFG task 50 regarding the bad interface module 18. If no testtone or the wrong test tone is detected, then at step 2118 the test loopis moved back to point C on the signal processing board 22 whichconnects the transmit and receive paths of the encoded connection of theDSP for the traffic channel being tested. The test tone is applied toeach of the four decoded connections of the DSP (e.g., similar to theidle DSP test) and if detected at step 2020, then it is determined atstep 2024 that the switching module 16 is bad and an alarm is sent tothe CNFG task 50 regarding the bad switching module 16 so that a requestto fail-over to a redundant switching module 16 can be made (if a spareboard is available) and FIT terminates. If no test tone or the wrongtone is detected at step 2020, however, then the test loop is moved topoint D on the signal processing module 22 MUSAC chip 21 in step 2022.The test tone is applied and if detected at step 2026, it is determinedthat the DSP on the signal processing board 22 allocated to the trafficchannel on the span being tested is bad at step 2028. An alarm is sentto the CNFG task 50 so that a new DSP can be remapped to the trafficchannel if possible. If no tone is detected at step 2026, however, thenthe test loop is moved back to point E on the switching module 16 atstep 2030. The test tone is applied and if detected at step 2032, it isdetermined that the signal processing board 22 is bad at step 2034 andFIT terminates. If no tone is detected at step 2032, however, then thetest loop is moved back to point F on the telephony support module 18MUSAC chip at step 2036. The test tone is applied and if detected atstep 2038, it is determined that the switching module 16 is bad at step2040 and an alarm is sent to the CNFG task 50 so that a failover requestto a redundant switching module 16 is initiated if possible. If no toneis detected at step 2038, however, it is determined that the telephonysupport module 18 is bad at step 2042 and an alarm is sent to the CNFGtask 50 so that a failover request to a redundant telephony supportmodule 18 can be made if possible.

FIG. 21 illustrates exemplary connections for a test tone for FIT of aland span according to an embodiment of the present invention. Incontrast to the air span example in FIG. 19, a land span (e.g., a PSTNspan) does not involve signal processing by a DSP and thus the signalprocessing module 22 is not involved in the test tone path. As shown inFIG. 21, a tone generator 191 on the telephony support module 18provides a test tone to a MUSAC chip 21 on the telephony support module18 which forwards the test tone to the switching module 16. Theswitching module 16 connects the test tone to a MUSAC chip 21 of aninterface module 20 which connects to a land span to be tested. Thereturn path for the test tone is the same path in reverse as illustratedin FIG. 21. As in an air span FIT, the initial test loop for a land spanFIT is formed by placement of a jumper cable on the land span connectingall of the transmit and receive channels and applying a test tone toeach of the timeslots on the span. If the test tone is not detected,then localization is performed to isolate the faulty component orresource processor (e.g., isolation to a replaceable unit).

FIG. 22 illustrates an exemplary flowchart of FIT for a land span. Asillustrated in FIG. 22, a test loop is initially established by applyinga jumper to the span to be tested, thereby connecting the transmit andreceive paths for each timeslot on the span. A test tone is thensupplied by the test tone generator for each timeslot. If the test toneis detected by the test tone detector for all of the 32 timeslots on thespan, then the test result is PASS, indicating that any problems areexternal to the switching platform 10. If no test tone or the wrong testtone detected, however, the test result is FAIL and the fault must belocalized in the same manner as described regarding FIT on an air span.For example, the test loop will be moved back to points B, C or D asnecessary to isolate the fault.

Referring to FIGS. 21 and 22, a test loop is established at point A onthe MUSAC chip 21 of the interface module 20 in step 2200. A test toneis connected to the transmit channel of the timeslot being tested instep 2202 and a test tone detector 192 is connected to the receivechannel of the timeslot in step 2204. If the proper test tone isdetected by the test tone detector 192 on the telephony support module18 at step 2206, then the test result is PASS in step 2208, there are noproblems with the circuits of the switching platform 10 and FITterminates. If no test tone or the wrong test tone is detected, however,then the test result is FAIL and the fault must be localized by movingthe test loop to point B at step 2210. At point B a loop connection ismade between the transmit and receive paths for the tested channel onthe switching module 16. If the test tone is detected at step 2112, thenit is determined that the span on the interface module board 20 beingtested is bad in step 2214 and an alarm is sent to the CNFG task 50regarding the bad interface module 18. If no test tone or the wrong testtone is detected, then at step 2116 the test loop is moved back to pointC on the telephony support module 18 MUSAC chip 21 at step 2216. Thetest tone is applied and if detected at step 2218, it is determined thatthe switching module 16 is bad at step 2030 and an alarm is sent to theCNFG task 50 so that a failover request to a redundant switching module16 is initiated if possible. If no tone is detected at step 22188,however, it is determined that the telephony support module 18 is bad atstep 2222 and an alarm is sent to the CNFG task 50 so that a failoverrequest to a redundant telephony support module 18 can be initiated ifpossible.

A few preferred embodiments have been described in detail hereinabove.It is to be understood that the scope of the invention also comprehendsembodiments different from those described, yet within the scope of theclaims. For example, the terms "controller," "processing circuitry," and"control circuitry" comprehend ASICs (application specific integratedcircuits), PAL (programmable array logic), PLAs (programmable logicarrays), decoders, memories, non-software based processors, or othercircuitry, or digital computers including microprocessors andmicrocomputers of any architecture, or combinations thereof.

Memory devices include SRAM (static random access memory), DRAM (dynamicrandom access memory), pseudo-static RAM, latches, EEPROM(electrically-erasable programmable read-only memory), EPROM (erasableprogrammable read-only memory), registers, or other memory devices knownin the art. Words of inclusion are to be interpreted as nonexhaustive inconsidering the scope of the invention.

Aspects of the claimed invention may be applied to switching systems forGSM mobile switches, PCS mobile switches, or in switches primarily usedfor switching land-based circuits. The telecommunications circuitsdescribed in the preferred embodiment were generally E1 or T1 spans, butaspects of the invention could be applied to platforms that switchlower- or higher-bandwidth circuits such as T-2, T-3, or SONET. Also,aspects of the invention could be applied to switch circuits ofbandwidths generally equivalent to E1 or T1 but having different framingformats.

Implementation is contemplated in discrete components or fullyintegrated circuits in silicon, gallium arsenide, or other electronicmaterials families, as well as in optical-based or othertechnology-based forms and embodiments. It should be understood thatvarious embodiments of the invention can employ or be embodied inhardware, software or microcoded firmware.

While this invention has been described with reference to illustrativeembodiments, this description is not intended to be construed in alimiting sense. Various modifications and combinations of theillustrative embodiments, as well as other embodiments of the invention,will be apparent to persons skilled in the art upon reference to thedescription. It is therefore intended that the appended claims encompassany such modifications or embodiments.

What is claimed is:
 1. A method for testing a component in a switchingplatform, comprising the steps of:periodically searching a configurationdatabase to identify a component to be tested, the configurationdatabase maintaining status information on components of the switchingplatform; and automatically performing a fault test on the identifiedcomponent.
 2. The method according to claim 1, further comprising thesteps of:if the fault test results in a pass condition, terminating thefault test; and if the fault test results in a fail condition,automatically performing a localization operation to isolate a source ofthe fail condition.
 3. The method according to claim 1, wherein the stepof automatically performing the fault test includes establishing an endto end test connection of the identified component.
 4. The methodaccording to claim 2, wherein the step of automatically performing thefault test includes establishing an end to end test connection of theidentified component and the step of performing the localizationprocedure includes establishing iterative loopback connections withinthe end to end connection until the source of the fail condition isisolated.
 5. The method according to claim 2, further comprising thesteps of:when the source of the fail condition is isolated, generatingan alarm identifying the source of the fail condition; in response tothe alarm, searching the configuration database to identify a redundantcomponent for the source of the fail condition; and if a redundantcomponent is identified, automatically failing over to the redundantcomponent.
 6. A method for testing a component in a switching platform,comprising the steps of:initiating a fault test on an identifiedcomponent, If the fault test results in a pass condition, terminatingthe fault test; and if the fault test results in a fail condition,automatically performing a localization operation to isolate a source ofthe fail condition.
 7. The method according to claim 6, furthercomprising the steps of:when the source of the fail condition isisolated, generating an alarm identifying the source of the failcondition; in response to the alarm, searching a configuration databaseto identify a redundant component for the source of the fail condition,the configuration database maintaining status information on componentsof the switching platform; and if a redundant component is identified,automatically failing over to the redundant component.